mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kompatibilität bei C Programmierung


Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: icke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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...).
Was bei einem Prozessor sauber funktioniert, kann bei anderen zum
verborgenen Problem werden.

Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie es aussieht ist C auch nicht mehr als ein etwas komfortabeller
Assembler

Aber wir suchen weiter ;-)

Danke

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der dsPIC hat mit dem normalen PIC nichts zu tun.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.