Hi Leute Ich bin relativ neu bei den MSP430ern und habe bisher mit C und der Gratis-Version des IAR Embedded Workbenches gearbeitet. Nun bin ich aber an deren Limite (maximal 4kb Objektcode) gestossen und möchte den Compiler wechseln. Am sympatischsten ist mir die MSPGCC-Toolchain. Ich überlege mir jedoch noch, ob ein Umstieg auf C++ sinnvoll wäre. Mit C++ möchte ich vor allem durch Klassen und Vererbung den Code besser gestalten. Das sollte ja zumindest theoretisch auch mit dem MSPGCC funktionieren, denn auf deren Webseite steht, dass es sich um einen C++-Compiler ohne libstdc++ (Standardbibliothek für C++) handelt. Nun frage ich mich, ob es in diesem Fall Sinn macht, C++-Code zu schreiben, jedoch die C-Standardbibliothek zu verwenden. Oder sollte man dies aus irgend einem Grund nicht tun? Und wie sieht es mit dem Overhead aus, der durch C++ entsteht? Hat diesbezüglich jemand Erfahrung? Oder soll ich doch bei C bleiben? Freundliche Grüsse Tom
C++ ergibt durchaus Sinn. Man muss allerdings etwas mit der Schere im Kopf programmieren, manches ist des Aufwands wegen wenig sinnvoll (virtual base classes, method pointers, ...), manches geht mangels Runtime-Support nicht. C++ neigt auch dazu, gelegentlich einen Copy-Constructor einzuwerfen wo man's gerne vermieden hätte. Es lohnt sich also, ab und zu einen Blick in den erzeugten Code zu werfen.
Was den Einfluss des Overheads auf die kompaktheit und das Laufzeitverhalten Deines Codes angeht, wird es von Deinen Anforderungen abhängen, ob es hinnehmbar ist oder nicht. Ich verwende den WinAVR für Atmel-Controller mit C++ (nicht exzessiv aber mit ein wenig Vererbung und vor allem mit der Möglichkeit, über den Einsatz von Konstruktoren automatische Initialisierungen vorzunahmen). Das geht, ich bin bis jetzt noch nicht an die Grenzen gestossen. Aber der ganze dynamische Kram (mit new und delete) fällt hier natürlich weg, was vielleicht in Anbetracht des geringen RAM-Speichers auf den µCs auch besser so ist. Gruß, Michael
Danke für eure Antworten! Mich wurmt vor allem, dass die Standard-Bibliothek nicht implementiert wurde. Ich seht damit also kein Problem? Assembler spreche ich leider auch noch nicht fliessen. Worauf soll ich genau beim generierten Code achten? Ich werde mich natürlich noch richtig in Assembler einarbeiten, jedoch hatte ich bisher keine Zeit dafür (Diplomarbeit). Ich werde mal ein paar Experimente starten und mich dann entscheiden. Kennt ihr vielleicht einen eleganten strukturierten Weg, um 'Funktionalität' (z.B. RS-232, RTC, MMC, o.ä.) möglichst einfach einzubinden? Worauf soll man konkert achten? Mit meinen Bibliotheken bin ich nicht ganz glücklich... bzw. ich suche bestätigung ;-). Ich bin halt auch beim Programmieren noch etwas grün hinter den Ohren. Ich arbeite nicht mehr an einem bestimmten Projekt, sondern ich versuche mir eine stabile Grundlage aufzubauen, um damit verschiedene Anwendungen auf einfache Art zu realisieren. Darum ist das oberste Kriterium Erweiterbarkeit. Gruss Tom
Wenn man nichts von Assembler versteht, kann man dem Code zumindest ansehen, ob er sehr umfangreich oder recht kurz geraten ist. Gruß, Michael
hmm, welche c++ funktionen brauchst du denn aus der std? man findet immer code von aus der std den man portirbaren kann. und wenn nicht, dann macht man sich diesen halt selbst. ich habe mich auch mal in c++ auf dem iarmsp versucht (vollversion). interessant war hierbei, das c++ code genauso effizient wie c code war (auch in anbetracht auf programmgröße). jedoch fragte ich mich, wozu ich unbedingt oop brauche, da solch ein programm verhältnismäßig überschaubar ist und man mit einer guten planung auch ohne auskommt. auch ist die arbeit bei kleinen programmen mehr als doppelt schreibintensiv, wenn man c++ verwendet. mfg KoF
@KoF: >>>jedoch fragte ich mich, wozu ich unbedingt oop brauche, da solch >>> ein programm verhältnismäßig überschaubar ist und man mit einer >>> guten planung auch ohne auskommt. auch ist die arbeit bei kleinen >>> programmen mehr als doppelt schreibintensiv, wenn man c++ >>> verwendet. 1. Nicht jedes Programm auf einem µC ist klein (wobei: alles ist relativ). 2. OOP erhöht die Wiederverwendbarkeit. Gewisse Elemente erhöhen die Sicherheit: Ich denke, das versehentliche Weglassen von Initialisierungsroutinen-Aufrufen verursacht einen hohen Prozentsatz der Fehlersuchzeit. Packt man solche Sachen in Klassen und Objekte, bei deren Erzeugung die Initialisierungen automatisch im Konstruktor vorgenommen werden, dann kann man es nicht mehr vergessen (bzw. man kann es gerade doch aber es passiert trotzdem :) ) Gruß, Michael
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.