Hallo,
da ich überwiegend in C Mikrocontroller programmiere, würde ich gerne
wissen in wie fern sich Embedded C++ vom normalen C++ unterscheidet.
Laut meinen Recherchen ist Embedded C++ eine Teilmenge von C++: Es sind
sehr viele Funktionen nicht mehr vorhanden.
Gibt es aber Besonderheiten von Embedded C++ gegenüber dem normale C++?
Oder kann jemand der C++ kann auch problemlos C++ auf Mikrocontrollern
programmieren (natürlich vorausgesetzt er kennt sich mit der Architektur
aus)?
Was muss ich berücksichtigen wenn ich C++ kann und C++ für
Mikrocontroller programmieren muss?
Ich würde gerne noch wissen, auf welchen Mikrocontroller im
professionellen Umfeld (Entwicklungsabteilungen spezialisiert auf
Embedded) gerne auf C++ programmiert wird oder Bibliotheken auf
C++-Basis.
Kann jemand seine Berufserfahrungen da teilen was gängig ist?
Embedded C++ ist eine sinnlos kastrierte Sprache die quasi tot ist. Man
benutzt einfach normales C++ und benutzt nicht geeignete Features
einfach nicht.
derjaeger schrieb:> Oder kann jemand der C++ kann auch problemlos C++ auf Mikrocontrollern> programmieren (natürlich vorausgesetzt er kennt sich mit der Architektur> aus)?
Nicht ganz so einfach, aber die Knackpunkte lernt man schnell. Nichts im
Vergleich zum Aufwand,C++ überhaupt erst mal gut zu beherrschen.
derjaeger schrieb:> Was muss ich berücksichtigen wenn ich C++ kann und C++ für> Mikrocontroller programmieren muss?
Hauptsächlich dass dynamische Speicher Verwaltung oft problematisch ist,
und die direkte Verwendung der meisten Container Klassen damit wegfällt
(ggf. Kann man sich mit eigenen Allokatoren behelfen, aber nicht ganz
einfach) . Exceptions fallen auch meistens raus, und Stream Klassen wie
std::cout sind ebenfalls meist viel zu aufwendig implementiert.
Der Gebrauch von C++ auf Microcontrollern ist verbreiteter als gemeinhin
angenommen wird. Die bei Bastlern, Einsteigern und auch einigen
Pragmatikern beliebte Arduino-Umgebung ist nämlich nichts anderes - die
sogenannten "Sketches" sind C++-Code, der in einer etwas speziellen
Umgebung verwendet wird (kein main(), stattdessen "setup()" und
automagisch zyklisch aufgerufene "loop()").
Da wird natürlich nicht der akademische Hechelkurs des "wer hat als
erster die neuesten Elemente der neusten Version des C++-Standards
eingesetzt" berücksichtigt, und --auch aufgrund der Einschränkungen der
Zielhardware-- nicht jede tolle Templatespielerei umgesetzt.
Aber C++ ist es trotzdem, und der Compiler dahinter ist der gute alte
g++.
>Embedded C++ ist eine sinnlos kastrierte Sprache die quasi tot ist.
Der Cross-Compiler "avr-g++" verwendet das normale GNU C++, richtig?
Die meisten offenen Compiler wie gcc (Texas Instruments, ATMEL, ARM)
unterstützen also nicht 'Embedded C++' sondern kompilieren ganz normal
in C++?
Ich war noch nie der Meinung, daß man alel Features von C++ tatsächlich
beherreschen und nutzen muss - gleiches gilt auch für Java.
Insofern überraschte es mich, hier zu elsen, daß es ein "Embedded C++"
gegeben hat. Davon habe ich noch nie gehört und ich wüsste auch nicht,
wozu eine spezielle C++ Variante gut sein soll.
Die einzige embedded spezifische Erweiterung, die ich mit vorstellen
könnte, wäre eine elegantere Syntax zum Adressieren und Ändern von Bits.
Aber das ist Jammern auf hohem Nivau, schließlich kann man das auch
zufriedenstellend mit Makros abdecken.
>Davon habe ich noch nie gehört und ich wüsste auch nicht, wozu eine spezielle C++
Variante gut sein soll.
Wahrscheinlich die gleiche Motivation wie C und MISRA-C. Wozu MISRA-C,
wenn es schon C gibt?
Dr Sommer schrieb:
>Exceptions fallen auch meistens raus, und Stream Klassen wie>std::cout sind ebenfalls meist viel zu aufwendig implementiert.
Deshalb macht dort das Arduino-Framework sein eigenes Ding. Das hat zwar
zur Folge, dass es in keinster Weise mehr zu cout und cin kompatibel
ist, dafür aber in die kleine MCU passt und trotzdem eine Erleichterung
bietet.
Hier direkt in's Framewok gegriffen:
'cin' Ersatz:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/Stream.cpp
'cout' Ersatz:
https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/cores/arduino/Print.cpp
derjaeger
>Wahrscheinlich die gleiche Motivation wie C und MISRA-C. Wozu MISRA-C,>wenn es schon C gibt?
MISRA finde ich gut, das begrenzt den Wildwuchs und verbessert die
Leserlichkeit des Codes. Schau dir mal die kryptischen Programmierstiele
von vor 30 Jahren an.
Da in der Automotive-Industrie mittlerweile Designtools vorgeschrieben
sind und diese meist UML und dessen Klassendiagramme unterstützt, wird
auch C++ irgendwann in Automotive einziehen und dann muss ein MISRA C++
her.
Scott Meyers (Gast)
>Leute, was'n los?>Da stellt einer die Un-Frage nach dieser Sprache im µC-Bereich, und es>keiner macht ihn nieder !?! Kopfschüttel ...
Die Zeiten sind vorbei. Die alten Knochen, die nur C konnten, sind
wahrscheinlich ausgestorben ...
C++ ist durch Arduino inzwischen so weit auf µC verbreitet, daß man sich
lächerlicht macht, wenn man dessen kommerzielle Tauglichkeit immer noch
verleugnet.
Auch hat das Bashing gegen Arduino und deren Nutzer stark nachgelassen.
Ich vermute, weil es langweilig geworden ist und weil die Arduino Nutze
keine kleine Minderheit mehr sind.
Aber keine Sorge, es wird bald neue "Opfer" geben, auf die der Pöbel
herum hackt.
Die Initiative haben damals vor allem japanische Firmen ins Leben
gerufen aber laut Stroustrup war EC++ schon 2004 tot ("... and if it
isn't, it ought to be." :D )Nachzulesen bei
https://en.wikipedia.org/wiki/Embedded_C%2B%2B
Also als eigene Sprache ist "Embedded C++" in der Welt da draußen
definitiv nicht mehr vertreten aber C++ auf Embedded-Geräten kommt immer
mehr in Mode. Sony hat z.B. bei seinen aktuellen Walkman-Produkten den
Application-Layer komplett in C++ verfasst. Lediglich der OS-Kernel und
die Treiber sind in C geschrieben. Wen es interessiert, der kann sich
den Vortrag bei Youtube ansehen. Leider sehr schlecht zu verstehen aber
technisch wie ich finde sehr interessant: https://youtu.be/T8fLjWyI5nI
>Die Initiative haben damals vor allem japanische Firmen ins Leben
Aha ... da wäre jetzt die Frage, ob der TO tatsächlich "embedded C++"
oder C++ auf Embedded-Systemen meint.
>Leider sehr schlecht zu verstehen aber>technisch wie ich finde sehr interessant: Youtube-Video "Developing Audio >Products with Cortex-M3/NuttX/C++11 - Masayuki Ishikawa, Sony"
Passend zu dem Video spielen die im STM32-Forum gerade mit Nuttx auf dem
F103:
http://www.stm32duino.com/viewtopic.php?f=45&t=2553&hilit=nuttx
Alle Steuergeräre könte man nach IEC61508 oder 26262 oder 50128 oder
DO178C oder... klassifizieren. Und überall ist verboten, die Adresse
erst in Runtime zu bekommen, weil sie invalid sein könnte. Alles "Early
bound" sein muss. Und C++ mit Vererbung und Virtual Funtion & Co. ist
gerade das Gegenteil. Keine Steueregeräte im Auto verwendet C++. Im
Infotainment ist das was anderes. Und SW für autonomes fahren ist noch
nicht zugelassen.....
>oder C++ auf Embedded-Systemen meint
Gemeint war normales C++ auf Embedded Systemen.
Das ein eigener Standard namens 'Embedded C++' existiert wusste ich
nicht.
Stefan U. schrieb:> Auch hat das Bashing gegen Arduino und deren Nutzer stark nachgelassen.> Ich vermute, weil es langweilig geworden ist und weil die Arduino Nutze> keine kleine Minderheit mehr sind.
Dann versucht dich mal mit Arduino Kenntnisse irgendwo zu bewerben.
Arduino nutzen halt einfach die Dummies.
Max schrieb:> Und C++ mit Vererbung und Virtual Funtion & Co. ist gerade das> Gegenteil.
Niemand zwingt dich, diese Features zu nutzen. C++ hat noch viel mehr zu
bieten.
Wobei sich schon die Frage stellt, wie man derart komplexe Software wie
Automotive ECUs und deren OS (Autosar, osek) entwickeln kann ohne
jegliche Nutzung von Funktionen Pointer (nichts anderes passiert ja
intern bei virtuellen Funktionen) und die dadurch gebotene Abstraktion.
Wenn ich eine OS-Funktion aufrufe die irgendwann später asynchron fertig
wird, wie übergebe ich dann einen Callback? Ein Funktionen Pointer
könnte ja invalid sein.
>Arduino nutzen halt einfach die Dummies.
Darf ich dann deine Aussage so verallgemeinern, dass jede Person, die
ein Evaluierungsboard/Entwicklungsboard verwendet auch ein Dummy ist?
Discovery-Boards, Nucleo-Boards?
Denn ein Arduino Board ist nix anderes als ein Entwicklungsboard.
Beweise das Gegenteil, dass das nicht so ist.
Wenn ich also schauen im Unternehmen nur schauen will ob eine Idee
umsetzbar ist, muss ich dann also sofort eine Platine per EAGLE
designen, fertigen, bestücken lassen und dann mit teurem Programmer
ausstatten?
Mein Freund ich habe schlechte Nachrichten für dich: Wenn in einem
Unternehmen etwas auf Machbarkeit geprüft werden will, dann kommen
solche Entwicklungsboard sofort in Frage. Warum? Weil sie zuhauf in der
Kiste rumliegen und für diesen Zweck da sind. Ich muss nur mein
USB-Kabel reinstecken und kann sofort Debuggen und mein Programm
runterladen. Ich muss keine Schaltung für den Mikrocontroller aufbauen.
Und für wieviel? Für 10 Euro! Dafür kriegst du nichtmal deine Platine
gefertigt.
>Dann versucht dich mal mit Arduino Kenntnisse irgendwo zu bewerben.
Wenn du nur "Arduino" in deinem Lebenslauf vorzuweisen hast, dann bist
du grundsätzlich falsch bei dieser Stelle.
derjaeger schrieb:> Wenn du nur "Arduino" in deinem Lebenslauf vorzuweisen hast, dann bist> du grundsätzlich falsch bei dieser Stelle.
Habe aber schon einige gesehen, die nur Arduino vorzuweisen hatten. Die
merken noch nicht mal, dass das völlig peinlich ist. Wenn ein erfahrener
Elektrotechniker zum schnellen testen ein Arduino nimmt, dann ist das in
Ordnung. Vielleicht hätte ich das oben erwähnen sollen.
Um mal etwas mit einem Mythos aufzuräumen: Man kann mit der
Programmierung von Arduinos durchaus Geld verdienen.
Zumindest sind so zwei meiner Jahresgehälter zusammen gekommen ( und die
liegen einiges über dem Ende der Steuerprogression ).
Gut, die Arduinos ( ARM Versionen ) waren wie oben erwähnt nur der
Mittel zum Zweck und eher die Ersparnis ein eigenes Board entwickeln zu
müssen.
Aber ich habe auch das Arduino-Framework drunter gelassen, weil es keine
Notwendigkeit gab, ein Multitaskingsystem o.ä. zu verwenden.
Und klar, bei einem Projekt, was aus um die 100 Files besteht nimmt man
dann auch nicht mehr die Arduino IDE.
Wer sich nochmal darüber informieren möchte, warum C gegenüber C++
obsolet geworden ist, da kann sich die in diesem Betrag genannten Infos
ansehen:
Beitrag "Informationen zu C vs C++ / aka Futter für die Diskussion"
Der Begriff "Embedded C++" ist eher zu verstehen als eine
Vorgesehensweise, die darüber reflektiert, wie groß der
Ressourcenverbrauch bestimmten Sprachfeatures ist und je nach Einsatz
und µC einige Dinge nicht nutzt.
Dr. Sommer schrieb:> Exceptions fallen auch meistens raus, und Stream Klassen wie> std::cout sind ebenfalls meist viel zu aufwendig implementiert.
Wenn man sie vollständig implementiert, vielleicht schon, aber eine
einigermaßen klein gehaltene Version kann durchaus besser sein als ein
printf. Der Vorteil ist nämlich, dass für jeden auszugebenden Datentyp
ein eigener Operator<< definiert ist, also eine eigene Funktion. Damit
muss nur der Code gelinkt werden, der für die Typen nötig ist, die man
tatsächlich ausgeben will. Bei printf dagegen muss immer alles
mitgelinkt werden, auch das, was im konkreten Programm gar nicht
benötigt wird. Deshalb gibt es ja so Krücken mit verschiedenen
printf-Versionen, von denen man dann über den Linker eine auswählen
muss, um zumindest mal die gröbsten Speicherfresser wie float
rausschmeißen zu können, wenn man sie eh nicht benutzt.
> Dann versucht dich mal mit Arduino Kenntnisse irgendwo zu bewerben.> Arduino nutzen halt einfach die Dummies.
Das ist Ok, viele Mitglieder dieses Forums sind Hobbyelektroniker ohne
den Wunsch, sich damit zu bewerben.
