Hi, was muss man eigentlich beachten, wenn man µC in C programmieren will und z.B bei einem späteren Wechsel der MCU z.B. PIC18 <=> ATmega nicht allzuviel änder will. Gibt es ungeschriebene Regeln, die man beachten kann, damit der Quellcode möglichst MCU-Typen unabhängig bleibt? Bernd
Streng an ansi standard halten, menus etc. am besten ohne spezielle hardwareabhängige Operationen implementieren. Ich würde Aktionen wie Displayausgaben, Timer, ADC oder was auch immer Hardwareabhängig ist in einzelne Funktionen packen, die vom Hauptprogramm ohne Änderung verwendet werden können. Also nur ganz konzentrierte Harwareanpassungen. Frage ist, ob das wirklich durchzuhalten ist. Wäre z.B. sicher blöd, wenn ein Prozessor auf einmal keinen linearen Speicher mehr hat, sondern zwischen Bänken umschalten und code nachladen muss, oder oder.
Ich dachte auch an so Dinge wie String-Literals im FLASH ablegen. Hier hat der C18 von Microchip dann einen Satz spezieller Funktionen um die Standard C Bibliothek sowohl auf RAM als auch auf Flash ROM Strings anzuwenden. Nur sind solche Sachen beim GCC bestimmt anders, oder? Zumindest heißen sie da anders.
> Ich dachte auch an so Dinge wie String-Literals im FLASH ablegen. Genau da liegt bei Harvard-Architekuren der Hase im Pfeffer. Wenn "portabel" mehr heisst, als den gleichen Compiler für andere Prozessoren nachzukaufen, sondern auch andere Compiler eingesetzt werden sollen, dann ist das nur bei von-Neumann Architekturen suber hinzubekommen (z.B. MSP430,ARM). Dazu kommt noch, dass man sich bei diversen 8-Bittern Gedanken um den Speicherort von Variablen machen muss und dementsprechend proprietäre Speicherklassenspezifikationen einsetzen muss. Das immerhin kann man mit Präprozessor-Makros in den Griff kriegen. Ein weiteres Problem sind prozessorspezifische Optimierungen (siehe http://www.mikrocontroller.net/articles/AVR_PIC_51-Vergleich#Wie_komplex_ist_interrupt-feste_Programmierung_von_I.2FO-Ports). Was bei einem Prozessor sauber funktioniert, kann bei anderen zum verborgenen Problem werden.
Wie es aussieht ist C auch nicht mehr als ein etwas komfortabeller Assembler Aber wir suchen weiter ;-) Danke
> Wie es aussieht ist C auch nicht mehr als ein etwas komfortabeller > Assembler Was kann C dafür, dass viele 8-Bit Microcontroller der Harvard-Linie frönen? Wenn Du diesen Ärger vermeides willst - es gibt Alternativen. Ich vergass oben beispielsweise 68xx.
Dadurch das es MCUs gibt, die besser geeignet sind, werden PIC und AVR auch nicht besser. Ein kleiner Hoffnungsschimmer ist aber vielleicht der dsPIC. Dieser kann zumindest einen Teil seines Flash-ROMs ins RAM einblenden. Momentan mache ich mir Gedanken, wie man trozdem was daraus machen kann. Multitasking wäre ja doch schön.
Es ist wohl sinnvoll, gewisse Sackgassen gar nicht erst zu betreten oder sich deren Einschränkungen sehr wohl bewusst zu sein. PIC, AVR, MCS-51 sind alle auf die eine oder andere Art und Weise nichtskalier- und nur schlecht portierbare Sackgassen. Damit will ich nicht sagen, daß man sich in Sackgassen nicht wohlfühlen kann; das geringe Verkehrsaufkommen sorgt für niedrige Lärmpegel ... und als Entwickler hat man mit Nischenwissen IMHO bessere Marktchancen als als reiner "Mainstream"-Entwickler. Also sollte man bei der Auswahl seiner Controller an die generelle "Richtung" denken, in die man sich bewegen möchte; genügt einem die Größe von PIC, AVR, MCS-51 etc., dann sind die nicht zu verachten. Sobald aber ein Wechsel von Prozessorarchitekturen vorherzuahnen ist, sollten Architekturen mit "Quirks" (wie beispielsweise die Harvard-Architektur) mit genügend Vorsicht behandelt werden. C auf einem MSP430 oder auch 68xx (HC11) ist geradliniger als C auf einem AVR oder auf der MCS-51-Reihe. Sofern die "kleine" Architektur mit memory-mapped-I/O arbeitet und eine "von-Neumann"-Maschine ist, sollte ein späterer Wechsel auf -beispielsweise- ARM kein unüberwindbares Problem darstellen.
Hier mal ein Beispiel, was sowohl auf dem 8051 (Keil C51), als auch auf dem AVR (WINAVR) läuft: http://www.mikrocontroller.net/forum/read-4-140631.html#new So schwer ist das also mit der Kompatibilität garnicht. Peter
Wenn's dir nichts ausmacht, dass alle Daten im ROM erst einmal ins RAM kopiert werden, dann stört die Harvard-Architektur wirklich nicht. Denn genau das passiert ja in diesem Beispiel.
@A.K. jetzt, wo Du es sagst, fällt es mir auch auf. Bei 8051 wird die Tabelle in den Flash (code) gelegt, da der ja generic bzw. memory specific pointer kann. Viele 8051-er haben ja nur 128/256 Byte RAM, deshalb sollte man es so machen. Aber beim AVR-Code geht die Tabelle in den RAM. Da ich beim AVR nicht unter Mega8 in C programmiere, habe ich ja auch massig 1024 Byte RAM, da kann man mal so verschwenderisch sein. Peter
Gegenbeispiel: Ein Mega32 mit 30KB belegtem Flash, davon je nachdem wieviel Tracking eincompiliert ist ca 4-6KB Daten. Von 2KB RAM sind ~1,5KB schon belegt. Auch ein Mega128 würde mir da nicht helfen.
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.