Moin :), ich habe eine C++17 Bibliothek geschrieben, die idealerweise auch im Embedded-Umfeld nutzbar sein soll. Die Vermutung liegt nahe, dass nicht alle C++ Features per se auf Embedded Plattformen verfügbar sind. Ich nutze u.a. - std::string - std::ostringstream - Exceptions (sind optional bzw. deaktivierbar) Mir steht aktuell keine C++ Toolchain für Embedded zur Verfügung und daher wollte ich euch fragen, ob eure Toolchain die o.g. Features unterstützt. Da diese intern ja irgendwie dynamisch Speicher verwalten und nicht jede Plattform einen Heap hat habe ich das ungute Gefühl, dass meine Lib für Embedded nicht nutzbar ist bzw. umfangreiche Anpassungen nötig sind um das zu ändern.
Ich habe zwei Embedded-Systeme. Auf einem wäre sie nutzbar, auf dem anderen nicht. ;-)
Danish B. schrieb: > die idealerweise auch im > Embedded-Umfeld Wenn du von 32 Bit Maschinchen sprichst, stehen dir sowohl string, als auch die iostream Geschichte zur Verfügung .... Bei den 8Bit, z.B. AVR, kannste das erstmal knicken. Die ganze LibC++ ist nicht dabei.
Slippin J. schrieb: > Ich habe zwei Embedded-Systeme. Auf einem wäre sie nutzbar, auf dem > anderen nicht. ;-) Magst du mir auch erzählen um welche Systeme es sich handelt und welche Toolchain (gcc?) du nutzt? Arduino Fanboy D. schrieb: > Wenn du von 32 Bit Maschinchen sprichst, stehen dir sowohl string, als > auch die iostream Geschichte zur Verfügung .... > > Bei den 8Bit, z.B. AVR, kannste das erstmal knicken. > Die ganze LibC++ ist nicht dabei. Damit kann ich leben. Wenn die ARMs (Cortex M0 ... Cortex A) unterstützt werden ist das für mich ausreichend.
Danish B. schrieb: > Slippin J. schrieb: >> Ich habe zwei Embedded-Systeme. Auf einem wäre sie nutzbar, auf dem >> anderen nicht. ;-) > > Magst du mir auch erzählen um welche Systeme es sich handelt und welche > Toolchain (gcc?) du nutzt? Das eine ist ein ARM mit Linux drauf (gcc-Toolchain). Darauf funktioniert deine Lib. Das ist andere ist ein STM32 mit deaktivierter dynamischer Speicherverwaltung. Darauf funktioniert deine Lib nicht. Beide sind 32 Bit Systeme.
Exceptions sind schoen. Was macht man damit ? Ein "Critical Exception" auf den Display zusammen mit "Abort, Cancel, Retry, Continue ?". zB im Kontrolraum, in der Talstation einer Seilbahn. Der Schluessel fuer den Kontrolraum ist beim Chef, vor Ort zwischen 8 und 5, und sonst nirgends ?
Danish B. schrieb: > Moin :), Moin, Moin, > Die Vermutung liegt nahe, dass nicht alle C++ Features per se auf > Embedded Plattformen verfügbar sind. Dynamische Speicherverwaltung würde ich in der Regel versuchen, zu vermeiden. Kannst Du das nicht anders lösen (String-Typen mit fester Länge z.B.)? Exceptions haben im Embedded Bereich wenig Verwendung. Die benötigten Ressourcen stehen in keinen Verhältnis zum Nutzen. Im Embedded Bereich hast Du halt selten wirkliche Fehler (die allermeisten Fehlersituationen sind bekannt und müssen eh irgend wie bearbeitet werden; der Rest sind Hardwarefehler ;-). > Mir steht aktuell keine C++ Toolchain für Embedded zur Verfügung und > daher wollte ich euch fragen, ob eure Toolchain die o.g. Features > unterstützt. Der gcc kann das sicherlich. Für beide features braucht es eigentlich keine besondere Hardware-Unterstützung. schöne Grüße, Torsten
Torsten R. schrieb: > Im Embedded Bereich > hast Du halt selten wirkliche Fehler (die allermeisten Fehlersituationen > sind bekannt und müssen eh irgend wie bearbeitet werden; der Rest sind > Hardwarefehler ;-). Wo ist da der Unterschied zu einer Anwendung auf dem PC? Wenn die Exception nicht behandelt wird und der Anwender die Exception zu sehen bekommt, hat der Entwickler in den meisten Fällen etwas falsch gemacht.
mh schrieb: > Wenn die > Exception nicht behandelt wird und der Anwender die Exception zu sehen > bekommt, hat der Entwickler in den meisten Fällen etwas falsch gemacht Typische Exceptions sind doch, dass Speicherplatz oder eine Datei fehlt. Alternativ ein Eingabegerät (Sensor) oder ein Ausgabegerät (Aktor) fehlt. Und dann steht das ganze, bis der Benutzer das behebt. Im Embedded ist das keine Option.
mh schrieb: > Wo ist da der Unterschied zu einer Anwendung auf dem PC? Wenn die > Exception nicht behandelt wird und der Anwender die Exception zu sehen > bekommt, hat der Entwickler in den meisten Fällen etwas falsch gemacht. Der Unterschied liegt meistens in der Komplexität der Applikation. Wenn ein Großteil des Codes aus Error-Propagation besteht und / oder Fehler nicht lokal handhabbar sind, dann sind Exceptions ein schönes Mittel, den Code schlanker zu bekommen. Fehler kann ich sowohl mit Exceptions, als auch ohne Exceptions ignorieren, nicht behandeln etc.
> Da diese intern ja irgendwie dynamisch Speicher verwalten und nicht jede > Plattform einen Heap hat habe ich das ungute Gefühl Geh mal davon aus das du in der Regel keinen Heap haben wirst. Wieso? Du muesstest dann fest einen Teil des Speicher reservieren der irgendwie vom Heap genutzt wird. Da ist es dann wesentlich speichereffizienter wenn man Variablen feste Groessen zuweisst. Ausser man hat ein komplexes Multitastkingsystem wo unterschiedliche Tasks nicht immer Speicher brauchen. Dann koennte man die Hoffnung haben so den Speicher mehrfach nutzen zu koennen. Allerdings was macht dann ein System wenn der Speicher mal nicht verfuegbar ist? Auf Festplatte auslagern? Ein Fenster aufmachen? Oder doch eher eine Maschine verschrotten? Olaf
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.