ANSI-C-Programmierung und Embedded-C-Programmierung



  • Hi,

    welche eigentliche Unterschiede gibt es zw. ANSI-C-Programmierung und Embedded-C-Programmierung?

    MfG
    Campus



  • Den Standard "Embedded-C" gibt es nicht.



  • Die meisten Embedded Compiler halten sich an den ANSI Standard, insofern gibts keinen Unterscheid. Allerdings muß man sehr auf den Speicherverbrauch achten. Mal eben malloc(10000), wie auf PCs geht nicht immer, einmal sprintf() aufgerufen und es kann sein, daß das Programm nicht mehr ins ROM/Flash passt. Auch steigt die main niemals aus, deswegen spricht man von einer Main "Loop". Ansonsten wird dort viel mit Interrupts gearbeitet. Ab mittelgroßen Controllern aufwärts kann man ein RTOS benutzen und hat dadurch Multitasking. Funktionen wie putchar/getchar benutzen oft die serielle Schnittstelle. Das ists, was mir auf die Schnelle einfällt, vielleicht hat noch jemand anders was zu sagen.



  • Es gibt halt meistens noch diverse Compilerspezifische besonderheiten die zusätzlich zum Ansi-C Umfang hinzukommen.

    Allgemein schreibt man natürlich Embedded-C Programme anders als Programme für einen PC. Das ergibt sich aber einfach durch die Möglichkeiten des uC und den gewünschten Einsatz.



  • KennerDerSzene_ schrieb:

    Es gibt halt meistens noch diverse Compilerspezifische besonderheiten die zusätzlich zum Ansi-C Umfang hinzukommen.

    Gut, aber die hat man auch bei Compilern für PC.

    Allgemein schreibt man natürlich Embedded-C Programme anders als Programme für einen PC. Das ergibt sich aber einfach durch die Möglichkeiten des uC und den gewünschten Einsatz.

    Ja, man programmiert sehr nah an der Hardware, man spricht die eingebauten Module des Controllers (Timer/DAC/ADC/IO Ports und mehr) direkt an.



  • Allgemein schreibt man natürlich Embedded-C Programme anders als Programme für einen PC.

    Wieso?
    Gutes Design und guter Programmierstil ändern sich nicht für embedded Programmierung.

    Das einzige was sich ändert ist die typische Art der Aufgaben die zu lösen sind.

    Wenn man im embedded Bereich ohne RTOS arbeitet muß man ich typischerweise die Routine für getc und putc selber schreiben, da diese Platform (Hardware) spezifisch sind.
    Wenn ein RTOS eingesetzt wird muss man dafür entweder eine Board Support Package kaufen oder selber erstellen. In diesem BSP werden die Harwarespezifika für das RTOS gelöst, z.B. auch das getc,putc



  • PAD schrieb:

    Allgemein schreibt man natürlich Embedded-C Programme anders als Programme für einen PC.

    Wieso?
    Gutes Design und guter Programmierstil ändern sich nicht für embedded Programmierung.

    Nicht ganz. Bei Embedded Systemen versucht man als Variablentyp so oft es geht "int" zu nehmen. Mit longs und chars können einige Controller nicht gut umgehen. Dafür muß der Compiler Code erzeugen, um die Macken des Controllers zu umschiffen und das Programm wird größer und langsamer dadurch. Float und double erfordern oft eine extra Library, die mehere KB des wertvollen ROMs kostet.



  • @Bug
    Bei den embedded Controllern bei uns Blackfin, und PowerQuicc II haben wir diese Problem nicht.
    Bei 8051 und Z80, 68360 konnte man schon beim Design darauf rücksichtnehmen.

    Aber Gutes Design nimmt auch immer die sinnvollen Datentypen.

    Was früher ab und zu Probleme macht/machte war float, aber nur wegen der Performance, dafür gibts aber auch
    fix pint mathematik und ähnliche Lösungsansätze.



  • PAD schrieb:

    Aber Gutes Design nimmt auch immer die sinnvollen Datentypen.

    Ja, aber im Unterschied zur PC-Programmierung muß man bei Embedded Systemen die "maschinenverträglichkeit" der Datentypen mindestens genau so berücksichtigen, wie ihre Eignung für den Algorithmus. Da fällt mir ein: Das könnte auch ein Grund dafür sein, warum Standardfunktionen wie getchar "int" zurückliefern und nicht "char".



  • Das selbe solltest du auch beim PC-Machen. Dort sind die typischen Probleme Alignment in Strukturen und Int64
    Man kann dort endlos an Performance lassen, wenn man sich ungeschickt verhält. Unnötiges Nutzen von zu kleinen sprich
    nicht int32 integeren für Berewchnungen macht auch keinen Spaß


Anmelden zum Antworten