Hi Leute, ich hab folgendes Problem: Ich hab bisher PIC12/16/18 in Assembler programmiert. Gab es in den Assembler Programmen mehrere asm Dateien, hab ich es bisher wie folgt Strukturiert(Beispiel mit PIC18F87J10): 1. File: Main.asm - Include Dateien: PIC18F87J10.INC System.INC Definitionen.INC 2. File: GPS.asm - Include Dateien: PICF87J10.INC Extern.INC Definitionen.INC 3. File: USART.asm - Include Dateien: PICF87J10.INC Extern.INC Definitionen.INC 4. File: System.INC - Die Datei enthält die Variablen Definitionen also z.B. GPSBuf res .32 ;GPS Empfangsbuffer - Die Datei enthält dazu die Glabalisierungen für Variablen damit diese von der GPS/USART.asm genutzt werden können, wie z.B. global GPSBuf ;GPS Empfangsbuffer - Die Datei macht außerdem die Funktionen der USART/GPS.asm für die Main.asm verfügbar z.B. extern GPS_Init ;GPS Initialisierungs Routine 5. File: Extern.INC - Die Datei macht alle Variablen für alle asm Dateien verfügbar z.B. extern GPSBuf ;GPS Empfangsbuffer 6. File: Definitionen.INC - Die Datei enthält alle Definitionen für die asm Dateien wie z.B. #define GPSEnable LATJ,5,ACCESS ;GPS On/Off Das ist der Aufbau wie ich Ihn bisher in meine Assembler Programme eingepflegt habe. Der Vorteil ist, das ich für Zusätzliche asm Files immer wieder die selben Include Dateien verwenden kann. Ich weiß jedoch nicht ob diese Struktur üblich ist oder nicht da ich mir das assemblern selbst begebracht habe. Meine Frage zwar auch wie ich es in Assembler richtig machen würde (falls das nicht schon der Fall ist) noch wichtiger für mich ist allerdings wie ich es in Zukunft richtig mache, wenn ich PIC32's in C Programmiere, da ich ich gerne auf die IDE von MikroElektronika MikroC umsteigen möchte. Diese hat den Vorteil das bereits unmengen von Bibliotheken mit eingebunden sind z.B. zum lesen/schreiben von SD Karten, Ethernet, USB, Bootloader usw. Meine Frage ist also: Wie sieht die Grundstruktur aus wenn ich in C programmiere ??? Wo mache ich meine Definitionen, wie benutze ich Header Dateien, wo muss welche Datei Includiert werden, ... gibt es da eine Grundidee wie das ganze aufgebaut sein sollte? Bitte gebt mir mal ein einfaches Beispiel gerne auch in Datei form für MPLAB, MPLAB X, MikroC oder Text File alles ist erlaub!
Ich würde eigentlich sagen, dass es keinen prinzipiellen Unterschied zwischen Assembler und C in der Hinsicht gibt, aber bei deiner Zusammenstellung ist schon etwas unpassend. An sich sollten alle exportierten Funktionen in einem Include deklariert werden und dieses Include sowohl beim Anwender als auch Definierer eingebunden werden. Als Beispiel für eine Funktion "int func(int x)" und eine Variable "struct data var", die beide in foo.c definiert und exportiert werden: foo.h enthält:
1 | int func(int x); |
2 | extern struct data var; |
Dazu muss auch die Definition von "struct data" vorhanden sein. Vor die Deklaration von func kann man auch "extern" schreiben, aber da deklarierte Funktionen ohne Definition automatisch extern sind, macht es in der Praxis niemand. foo.c enthält die Definitionen:
1 | #include "foo.h" |
2 | |
3 | int func(int x) |
4 | {
|
5 | /* usw ... */
|
6 | }
|
7 | |
8 | struct data var = { /* Initialisierung falls nötig */ }; |
(Alle Funktionen und Variablen, die nicht static deklariert sind, werden zum Linken exportiert.) Die Anwender der Funktion und Variablen müssen auch foo.h inkludieren. Der springende Punkt bei dieser Methode ist, dass sowohl Anwendung als auch Definition immer exakt die selben Deklarationen verwenden. Dadurch kann es nicht passieren, dass die Definition nicht mit der Anwendung kompatibel ist ohne dass es einen Fehler vom Compiler gibt. Man kann das auch vereinfachen und statt jedem .c ein dazugehöriges .h zu spendieren einfach alle in einer globalen .h zusammenzufassen. Der Nachteil dabei ist, dass alle .c dann von dieser einen .h abhängen und deshalb alle neu übersetzt werden müssen wenn sich diese ändert. Das schlägt dann bei größeren Projekten durch, wenn die Zeit zum Übersetzen signifikant wird.
Oli Holli schrieb: > Meine Frage ist also: Wie sieht die Grundstruktur aus wenn ich in C > programmiere ??? > > Wo mache ich meine Definitionen, wie benutze ich Header Dateien, wo muss > welche Datei Includiert werden, ... gibt es da eine Grundidee wie das > ganze aufgebaut sein sollte? Es gibt natürlich unendliche viele Möglichkeiten, so etwas zu machen, liegt letztendlich an Dir und Deinen Vorlieben. Ein Tip, falls es ein größeres Projekt wird: Teile Das Projekt in mehrere hierarchische Ebenen auf, ähnlich dem ISO/OSI-Modell (siehe Wikipedia): Ganz unten kommen die hardwarenahen Sachen (z.B. "Treiber" für UART, SPI, EEPROM usw). Mit zunehmender "Höhe" werden die Ebenen dann immer abstrakter. Die Ebenen müssen zueinander sauber gekapselt sein, d.h. nur über genau definierte Schnittstellen darf die Ebene x mit der Ebene x+1 kommunizieren. Das ISO/OSI-Modell ist dabei wirklick ein perfektes Beispiel.
Bronco schrieb: > Das ISO/OSI-Modell ist dabei wirklick ein perfektes Beispiel. leider aber wenig effizent, und teilweise nicht umsetzbar. z.b. wird mittlweile die TCP-Prüfsumme von der Netzwerkkarte berechnet - diese sollte aber TCP gar nicht kennen. Auch das Verpacken von Packeten ist sehr ineffizent auf einem µC. Es müssen vorne und hinten daten eingefügt werden, dafür muss neue speicher angefordert werden oder die Daten versschoben werden, beiden ist nicht effektiv.
Peter II schrieb: > leider aber wenig effizent, und teilweise nicht umsetzbar. Ich meinte: Das ISO/OSI-Modell ist ein gutes Beispiel für eine Software-Architektur mit mehreren Ebenen. Es geht doch nicht darum, TCP auf einem µC umzusetzen.
Danke für die Antworten. @ Andreas Da es hauptsächlich um den Grundaufbau geht ist das genau der Part den ich gesucht habe, danke. @Peter + Bronco Das ISO/OSI Modell werd ich mir auch noch anschauen und mal versuchen es von der Theorie in die Praxis umzuwandeln. Änderungen die dem praktischem Vorteil dienen kann ich dann nach belieben einpfegen da nur ich das Prog vor Augen haben werde. Hat vielleicht auch schon jemand Erfahrungen mit der IDE von MikroElektronika "MikroC für PIC32" gemacht. Auf den ersten Blick sieht die IDE echt gut aus. Es werden diverse Bibliotheken automatisch eingebunden, alles ist sehr übersichtlich gegliedert, es gibt eine Fester zum übersichlichen setzen der Konfigurations Bits, einen Assistenten um Interrups zu erstellen, und alles für 250,- Takken, und, und und - Aber wird das C Prog effektiv compiliert ? - Der Source Code der Bibliotheken ist nicht einsehbar, sind die einigermaßen Bugfrei? Wenn einer was weiß oder wen kennt, der wen kennt, der wen kennt, dann bitte mal was dazu Posten.
Oli Holli schrieb: > Hat vielleicht auch schon jemand Erfahrungen mit der IDE von > MikroElektronika "MikroC für PIC32" gemacht. Warum willst Du unbedingt diese IDE? Von Microchip gibt's doch auch einen C32-Compiler, was gefällt Dir daran nicht? Du kannst Dein C-Projekt grundsätzlich mit jedem Editor (Programmer's Notepad, CodeWright, Eclipe usw) programmieren und dann im MPLAB laufen lassen.
@Bronco ich arbeite schon eine ganze weile mit MPLAB und bin auch mit dem Assembler Teil der IDE ganz zufrieden aber die C Compiler machen für meinen geschmack eine sehr großen Code beim Compilieren, wenn ich selber in Assembler schreibe hat der Code nur 20-50% der Größe (beim kostenloser C Compiler). Die Neue MPLAB X mit XC Compilern ist leider auch nicht besser was das angeht. Darüber hinaus bin ich in C "noch" nicht gerade ein Profi und finde daher die einbindung der Microchip Bibliotheken recht anstrengend bis unverständlich. Speziell die Doku der Bibliotheken geht mir ein bißchen auf die nerven. MikroC ist da wirklich einige Schritte weiter. Man kann die Configs Bits in 30 Sekunden fehlerfrei einstellen ohne das Datenblatt zu zückken. Und Bibliotheken gehen wie gesagt automatisch, einfach die Funktion im Prog benutzen und fertig. Kein 400 Seiten Datenblatt, kein Header, keine Variablen erstellen. Ein Pic18 hab ich dort in 4 Stunden zu einem 50 Kanal-PWM Baustein programmiert. Die Infos zur Software und den Bibliotheken sind komplett und übersichtlich in der IDE Hilfe.
Oli Holli schrieb: > aber die C Compiler machen für > meinen geschmack eine sehr großen Code beim Compilieren, wenn ich selber > in Assembler schreibe hat der Code nur 20-50% der Größe (beim > kostenloser C Compiler). Wenn ich Dich richtig verstehe, redest Du gerade von einem 8-Bit-PIC, oder? Die Architektur der 8-Bit-PICs ist grundsätzlich leider nicht so gut für C geeignet, wohingegen moderne Archikteturen (wie PIC32, aber auch z.B. der AVR) spezielle für gute C-Unterstützung entwickelt wurden. Bei PIC32 & Co geben sich unterschiedliche C-Compiler nicht mehr viel, es sei denn, daß bestimmte Funktionen explizit abgeschaltet sind (wie z.B. die höheren Optimierungslevel bei den kostenlosen Eval-Paketen). > Und Bibliotheken gehen wie gesagt automatisch, einfach die Funktion im > Prog benutzen und fertig. Kein 400 Seiten Datenblatt, kein Header, keine > Variablen erstellen. Das ist aber eine Sache, die Du mit ein bissel C-Erfahrung in Nullkommanix im Griff hast. > Die Infos zur Software und den Bibliotheken sind komplett und > übersichtlich in der IDE Hilfe. Okay, das ist ein Argument.
Ja es ist von 8 Bittern die rede. Die 32 Bitter können natürlich mit zahlen größer 255 viel besser umgehen was ja in C schnell erreicht ist und bei einem 8 Bitter den Code natürlich um einiges aufbläst. MPLAB X gefällt mir übrigens vom Aufbau auch sehr gut und der Benutzeroberfläche auch sehr gut. Ich denke ich werde dem mikroC dennoch ne chance geben, für mich als 32 Bit Neuling scheint das nach wie vor einen leichten Einstieg zu ermöglichen. Falls 490 der 500 Bibliotheken nicht funktionieren, oder die C Programme vor dem Compilieren kleiner sind als nachher dann komm ich wieder zurück zu MPLAB.
Oli Holli schrieb: > Ja es ist von 8 Bittern die rede. Die 32 Bitter können natürlich mit > zahlen größer 255 viel besser umgehen was ja in C schnell erreicht ist > und bei einem 8 Bitter den Code natürlich um einiges aufbläst. Das hat damit nichts zu tun (sonst gäbe es ja keine gut-in-C-zu-programmierenden 8-Bit-µCs). Es gibt einfach gewisse Details in der Architektur (Registersatz, das Vorhandensein bzw. Fehlen bestimmter Befehle usw.), die entscheidend dafür sind, ob sich C gut abbilden läßt oder nicht. Außerdem ist es so, daß man komplexe Architekturen (mit Cache, Instruction-Pipeline usw.) viel besser in C programmieren kann als in Assembler, weil die Hersteller (die ihren µC natürlich am besten kennen) ihr ganzes Wissen und ihre Erfahrung im C-Compiler abbilden können. D.h. der C-Compiler kennt alle Tricks und Kniffe, um den µC optimal zu bedienen, damit sich der Programmierer auf seine eigentliche Aufgabe konzentrieren kann.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.