Embedded Programmierung mit C++ / Stdlibc++
-
Ich interessiere mich in letzter Zeit verstärkt für den Embedded Bereich und habe da noch sehr wenig Erfahrung. Wenn ich mir allerdings meine x86 Programme in C++ angucke, dann sind die für den Embedded Bereich wohl kaum zu gebrauchen.
Deshalb gleich zwei Fragen an die Experten:Gibt es spezielle Standardbibliotheken für den Embedded Bereich? Ich finde es macht einen großen Unterschied aus, ob ich ein Programm mit oder ohne stdlibc++ programmiere. Ganz besonders iostream bläht die Binaries unnötig auf. Was ist die Lösung? Gibt es spezielle Bibliotheken oder nutzt man die libc?
Gibt es Tutorials/Bücher wie man möglichst performanten C++ Code entwickelt und trotzdem minmalen Speicherbedarf und Programmgröße erreicht?
-
es gibt für notorische c++ fanboys ec++ mit abgespeckten libs. der kenner verwendet allerdings pures, gutes, altes C und assembler.
-
C++ wird in den wenigsten Fällen benutzt, nur auf "fetten" Controllern die genug Resourcen haben. Meistens wird C verwendet und die Controllerhersteller liefern i.d.R. auch für ihre Plattform passende Libraries mit.
Wenn du wirklich effektiv für µC programmieren willst, dann solltest du auch C statt C++ benutzen.
Was die Tipps und Tricks angeht - Da gibts genug Sachen die man im µC Umfeld optimieren kann gegenüber einen normalen PC. Denke dazu wirds auch im Internet genug Seiten geben. Bücher zu dem Thema gibts auf jeden fall, spontan fällt mir nur keins ein
-
Kommt halt drauf an was du machen willst. Für die "kleinen" µc ist C mit Assembler sicherlich besser geeignet. Aber wenn du zum Beispiel Programme für Intels PXA2xx schreiben willst, dann kannst du auch normales C++ benutzen. Du kannst dir ja das Buch hier mal anschauen:
C und C++ für Embedded Systems
Ich hab es auch. Allerdings fand ich es nicht so gut, da der ARM Teil (weswegen ich das Buch gekauft hatte) imho zu klein ist.
-
-
Kann man so allgemein IMO gar nicht sagen : kommt sehr auf den Controller, den mitgelieferten Compiler und auch den Anwendungsfall an. In sicherheitskritischen Systemen wird sehr oft mit embedded C++ (==kastriertes C++) und teilweise auch ohne dynamischen Speicher gearbeitet um Defragmentierungen zu verhindern. Das schließt die Stdlib schon weitestgehend aus.
Die Tatsache das dort viel mit C gearbeitet wird hat wenig damit zu tun, das es für embedded besonders toll wäre, sondern hat meist eher historische Gründe.
Viele Grüße,
Tobias
-
TheBigW@Work schrieb:
In sicherheitskritischen Systemen wird sehr oft mit embedded C++ (==kastriertes C++) und teilweise auch ohne dynamischen Speicher gearbeitet...
In sicherheitskritischen Bereichen wird gar nicht mit C und C++ gearbeitet.
-
Safety Critical System schrieb:
TheBigW@Work schrieb:
In sicherheitskritischen Systemen wird sehr oft mit embedded C++ (==kastriertes C++) und teilweise auch ohne dynamischen Speicher gearbeitet...
In sicherheitskritischen Bereichen wird gar nicht mit C und C++ gearbeitet.
Ohne eine genauere Definition von "sicherheitskritisch" ist diese Aussage eigentlich void.
-
Tim schrieb:
Ohne eine genauere Definition von "sicherheitskritisch" ist diese Aussage eigentlich void.
sicherheitskritisch ==> programmierfehler bedeuten gefahr für leib und leben, und/oder hohe materielle schäden.
-
definition: schrieb:
Tim schrieb:
Ohne eine genauere Definition von "sicherheitskritisch" ist diese Aussage eigentlich void.
sicherheitskritisch ==> programmierfehler bedeuten gefahr für leib und leben, und/oder hohe materielle schäden.
Dann ist die Behauptung, dass dort C und/oder C++ nicht eingesetzt wird, falsch.
-
definition: schrieb:
Tim schrieb:
Ohne eine genauere Definition von "sicherheitskritisch" ist diese Aussage eigentlich void.
sicherheitskritisch ==> programmierfehler bedeuten gefahr für leib und leben, und/oder hohe materielle schäden.
Dann ist aber sogut wie kein System auf der Welt in C oder C++ programmiert. Und das wiederrum ist ja wohl eher unwahrscheinlich. Schon alleine wenn ich von meinem T-NET-Anschluss telefoniere, kommt mind. ein System ins Spiel, das mit C oder C++ programmiert sein wird. Und du willst mir jetzt erzählen, das eine Telekommunikations-Infrastruktur nichts mit Sicherheit zu tun haben kann? Ich kann nur daran erinnern, als der Fluglotze in der Schweiz kein Telefon hatte (wurde gerade gewartet), deshalb die Flugzeuge über den Bodensee kollidiert sind.
Ihr denkt alle ziemlich kurzsichtig, wenn ihr meint, das C oder C++ in der Aufrechterhaltung der Welt keine Rolle spielt. Egal was die Menschen täglich machen bzw. benutzen, kann ein materieller oder menschlicher Schaden entstehen. Irgendwo in einer Kette, ist höchstwahrscheinlich ein Stück C- oder C++-Code mit im Spiel. Wer was anderes behauptet, ist irgendwie weltfremd.
-
Tim schrieb:
definition: schrieb:
Tim schrieb:
Ohne eine genauere Definition von "sicherheitskritisch" ist diese Aussage eigentlich void.
sicherheitskritisch ==> programmierfehler bedeuten gefahr für leib und leben, und/oder hohe materielle schäden.
Dann ist die Behauptung, dass dort C und/oder C++ nicht eingesetzt wird, falsch.
Ja, denn wie überall gibt es auch dort Wahnsinnige, die sich der Risiken nicht bewußt sind (Buffer Overflows, Wild Pointers, ...) und sie treiben einen irren Testaufwand.
-
Artchi schrieb:
Egal was die Menschen täglich machen bzw. benutzen, kann ein materieller oder menschlicher Schaden entstehen. Irgendwo in einer Kette, ist höchstwahrscheinlich ein Stück C- oder C++-Code mit im Spiel.
Allein daß es so ist, heißt nicht, daß es gut ist, wie es ist.
-
Angsthase schrieb:
Tim schrieb:
definition: schrieb:
Tim schrieb:
Ohne eine genauere Definition von "sicherheitskritisch" ist diese Aussage eigentlich void.
sicherheitskritisch ==> programmierfehler bedeuten gefahr für leib und leben, und/oder hohe materielle schäden.
Dann ist die Behauptung, dass dort C und/oder C++ nicht eingesetzt wird, falsch.
Ja, denn wie überall gibt es auch dort Wahnsinnige, die sich der Risiken nicht bewußt sind (Buffer Overflows, Wild Pointers, ...) und sie treiben einen irren Testaufwand.
So etwas wird halt nicht von Informatikern oder ähnlichem entwickelt. Das erhöht die Sicherheit natürlich ungemein!
-
Danke für Eure Beiträge!
Macht es eigentlich Sinn, oder kommt es häufiger in Praxis vor, C++ ohne die STL (und iostreams) einzusetzen? Ich habe mal ein wenig rumgespielt und wenn ich auf die STL verzichte, habe ich deutlich kompaktere Binaries.
-
Ohne konkretere Informationen zu deinem "embedded" Projekt kann man da wenig sinnvolle Tips geben. Dazu ist der Bereich "embedded" einfach viel zu groß.
-
Die Frage bezog sich jetzt nicht konkret auf eine Architektur oder auf den Embedded Bereich, sondern mehr auf den Zusammenhang zwischen STL (und iostreams) und der daraus resultierenden Programmgröße. Bei meinem Embedded Bereich handelt es sich primär um die Intel ixp4 Familie.
-
Es gibt mehrere alternative stl-Implementierungen, die wesentlich kleiner sind, z. B. uClibc++. Die habe ich unter FreeWRT verwendet. Sie ist vollständig genug, um mein Tntnet damit laufen zu lassen. Und Tntnet verwendet die STL und iostreams.
-
Du könntest die STL schlanker machen. Ich hab mal gelesen das das bei vielen komerziellen Projekten so gemacht wird.
-
Ich verwende für einen Experimental-Roboter namens Nibo sowohl C als auch C++-Programme. Letzteres geht ganz gut, wenn man ein paar Randbedingungen beachtet. Siehe: http://www.henkessoft.de/Roboter/Nibo.htm und http://www.roboternetz.de/phpBB2/viewtopic.php?t=31963&postdays=0&postorder=asc&start=66
Das geht, weil hier ein ATmega128 mit 4 KB SRAM - via I²C flankiert durch zwei ATtiny44 - eingesetzt wird.
http://nibo.editthis.info/wiki/Haupt-Controller
http://nibo.editthis.info/wiki/ATmega128