Moin Zusammen, Ich baue gerade ein größeres Projekt für das STM32F4 Discovery. Da der F4 massig Speicher hat, dacht ich mir probier ichs mal mit C++ im embedded Bereich. Nun zu meiner Frage, wie macht ihr das mit den C Librarys? Also ich benutze die StandardLib von ST so wie die USB-OTG und die HOST Lib von ST dazu noch FreeRTOS und HelixMP3... Das sind alles Libs die in C geschrieben sind, für FreeRTOS gibts die FreeRTOS Extension Class die lediglich als Wrapper dient. Wenn ich jetzt über meinen Code schaue sieht der aus wie mein C-Code ich benutze die C Funktionen direkt, und mache Cpp Code nur für meinen Display Treiber den ich mit eine Virtuellen Klasse etwas generisch geschrieben habe. Wie macht ihr das mit C-Lib im C++ Code? schreibt ihr Wrapper, nutzt ihr die einfach so und macht euren eigenden Code in C++? Ich hatte mir eigendlich mehr von der Nutzung von C++ versprochen, aber da ich noch nicht viel Erfahrung mit C++ habe mag das auch an meinem beschränkten Kenntnissen liegen oder daran das ich noch recht nahe ander Hardware Programmiere und die ganzen Userinterface Geschichten noch nicht geschrieben habe, vllt lohnt es sich ja da. MfG Tec
Tec Nologic schrieb: > Wie macht ihr das mit C-Lib im C++ Code? schreibt ihr Wrapper, nutzt ihr > die einfach so und macht euren eigenden Code in C++? Erst mal weiterbenutzen. Im Laufe der Zeit stellt sich dann schon raus, welche Komponenten von einem darübergelegten Klassenaufbau profitieren würden. > Ich hatte mir eigendlich mehr von der Nutzung von C++ versprochen, Du benutzt ja offenbar noch gar keine OOP. Von daher ist es nicht weiter verwunderlich, dass dein C++ momentan noch wie C (mit Klassen) aussieht. > nahe ander Hardware Programmiere und die ganzen Userinterface > Geschichten noch nicht geschrieben habe, vllt lohnt es sich ja da. Kommt schon noch. Wenn du erst mal den Dreh raus hast, wie du Vererbung und Polymorphie zu deinem Nutzen einsetzen kannst, ändert sich die Sachlage.
Moin Karl Heinz, Danke für deine Antwort. Naja bei dem Displaytreiber klappte das schon ganz gut, das war mein erster Versuch, Polymorphie zu nutzen, aber das ist das einzige in meinen 200K Code der rest ist wie du sagst C mit Klassen. Aber ich werd da mal am Ball bleiben. Was ich mich noch frage hat das Linken von C Code gegen C++ Code auswirkungen auf die Codesize? Mir kommt mein Code doch recht großvor. Klar ich hab n paar riesen Libs drin. Aber wenn ich meinen Code mit dem STM32F4 Beispiel AudioPlay and Record aus dem Discovery Package vergleiche, spiele ich MP3 vom Stick und die wave, ich hab also FreeRTOS + EC + Helix mehr drin und das Beispiel hat 34k mit O0 und mein Code >200k Code das wundert mich dann doch. Vllt mache ich ja was falsch. RTTI und Exceptions sind aus, Alle Objekte sind global angelegt, damit die nicht auf dem Heap liegen. MfG Tec
Tec Nologic schrieb: > Alle Objekte sind global angelegt, damit > die nicht auf dem Heap liegen. und warum? Wenn sie auch global gebraucht werden ist ja gut. Wenn es aber nur objekte sind die in einer funktion notwendig sind dann macht das wenig sinn. hast du Templates verwendet, diese erzeugen nicht viel code? Es gibt eigentlich eine auswirkungen wenn man C funktionen aus c++ aufruft. Das sollte sie nicht auf die codegröße auswirken.
Tec Nologic schrieb: > Was ich mich noch frage hat das Linken von C Code gegen C++ Code > auswirkungen auf die Codesize? Normalerweise nicht. Aber probiers aus: Mache ein leeres C int main() { } compiliere und linke es. dann dasselbe mit dem C++ Compiler. Die Exe-Size sollte in etwa die gleiche sein. Es kann natürlich sein, dass die Runtime-Lib deines C++ ein wenig größer ist, aber das ist normalerweise eine Konstante. D.h. dein EXE ist ganz einfach um, hausnummer, 10k größer. Aber diese 10k verändern sich nicht. Damit hast du die Basiszahlen. Und dann veränderst du dieses Minimalprogramm in die Richtung in die dein Verdacht fällt, dass du unbemerkt Code dazukriegst.
Kan asta schrieb: > Karl Heinz Buchegger schrieb: >> Exe-Size > > Target x86 win32 ? :-) Old habit Manchmal achte ich nicht drauf und bezeichne das ausführbare Programm als 'das EXE' auch wenn es nicht für die PC-Microsoft-Schiene gedacht ist.
Karl Heinz Buchegger schrieb: > und bezeichne das ausführbare Programm > als 'das EXE' Na du bist mir ja einer. Dann nenn es wenigstens "die Exe(-Datei)".
Moin, Wegen der Codesize hatte ich vor das Projekt testweise auf c zu portieren. Das wollte ich aber erst machen wenn das jetzige einen vernünftigen Stand hat. Templates habe ich bisher nicht genutzt weil ich nicht viele gleiche Strukturen habe. Wie ich bereits geschrieben habe bin ich noch dabei die ganze benötigte Hardware mit einer "Highlevel" Api auszustatten. Wenn wer interesse hat der Code ist hier zu finden. http://code.google.com/p/thundercyer-the-alarm-clock/ ich bin für jeden Tip und Hinweis dankbar MfG Tec
Tec Nologic schrieb: > Wenn wer interesse hat der Code ist hier zu finden. > http://code.google.com/p/thundercyer-the-alarm-clock/ 114MB in einem Zip-File(!) Was habt ihr denn da alles drinnen?
Moin, Da müsste das GitRepository mit drin gepackt sein :) Außer dem lege ich immer alle Libs mit im Projekt ab. Das Zip was da drin steht ist leider aber schon alt. nichts desto trotz kannst du einen Endruck bekommen. Das Projekt ist Eclipse mit Arm Plugin und Yagarto als Toolchain Am einfachsten geht das wenn du Mit Eclipse und EGit dir den Code ziehst, falls du die Möglichkeit dazu hast. Oder mal unter Source/Browse gucken. MfG Tec
Kan asta schrieb: > Na du bist mir ja einer. Dann nenn es wenigstens "die Exe(-Datei)". Na du bist mir ja einer (ein Erbsenzähler) EXE steht für executable, meines Wissens hat Microsoft auf den Begriff kein Patent oder Gebrauchsmuster.
Tec Nologic schrieb: > Mir kommt mein Code doch recht großvor. > Klar ich hab n paar riesen Libs drin. Aber wenn ich meinen Code mit dem > STM32F4 Beispiel AudioPlay and Record aus dem Discovery Package > vergleiche, spiele ich MP3 vom Stick und die wave, ich hab also FreeRTOS > + EC + Helix mehr drin und das Beispiel hat 34k mit O0 und mein Code >>200k Code das wundert mich dann doch. Wie wird gelinkt? Mit "archives" oder zumindest mit gc-sections ? Tec Nologic schrieb: > Wegen der Codesize hatte ich vor das Projekt testweise auf c zu > portieren. Zu 99% wird sich an der Code-Größe nicht viel ändern. Tec Nologic schrieb: > Das Zip was da drin steht ist leider aber schon alt. Toll. Und die neuen Versionen sind geheim. > 114MB in einem Zip-File(!) Ist da ein Makefile drin?
Roland H. schrieb: >> 114MB in einem Zip-File(!) > > Ist da ein Makefile drin? nein, aber dafür viele debug binarys
Moin, Das ArmPlugin generiert die Makefiles alle selber. die müssten im DebugOrdner liegen. Die Version im Repo ist sehr aktuell, ich werde heute abend mal die aktuelle Version hochladen auch als Zip, die spielt dann MP3 hoffendlich fehlerfrei. Edit: ich bringe zumindest die Zip mal auf den neuesten Stand. mit Eclipse und EGit einfach über File->Import und dann Import Git Projekt da den Ordner als Local Repository wählen. Edit2: leider geht das von hier doch nicht, ich mache das wenn ich heute Abend zu Hause bin. MfG Tec
So hab mal n neues Zip gemacht, MP3 läuft, aber wie ich gesehen habe machen das hier auch noch andere :) siehe hier: Beitrag "STM32F4 Discovery MP3 Player - komplett mit Code" Mir gehts aber eher um C++ als um das Mp3 effizient abspielen. MfG Tec
Tec Nologic schrieb: > So hab mal n neues Zip gemacht Da fehlt immer noch das "Top level" Makefile ;-) Ich kann's deshalb nicht wirklich prüfen, zumindest in dem Debug/Makefile finden sich Spuren von gc-sections beim Linken. Ob allerdings die Sourcen auch dafür kompiliert werden? Im map-File scheibt er auch etwas von "discarded input sections". Das scheint also zu passen. Wo ist denn nun eigentlich das Problem? Mach doch einfach mal ein Listing mit nm für alle Funktionen, sortiert nach Größe.
Moin Roland, Das Problem an sich war lediglich die Frage wie ich mit C Libs in einem Cpp Projekt ambesten verfahre. Speziell Callbackfunktionen aus C Libs sind ein Problem im Zusammenspiel der beiden Sprachen. Eben deshalb erhärtete sich bei mir die Vermutung das die unerwartet große Codesize aus Problemen zwischen C und C++ herrührt. Das Makefile das er generiert ist im Unterordner Debug zu finden. Ich habs mal angehängt. Was nm angeht, muss ich gerade mal gucken wie ich das als Postbuildstep bei Eclipse einstelle. MfG Tec Ps ich hoffe du kannst es dann Compiieren sonst muss ich mal eines schreiben.
welche Flags muss ich nm geben damit der mir die Symboltable lesbar ausgibt. Bzw kann man die in eine textdatei ausgeben? die Liste ist ellen lang die nm ausgibt. MfG Tec
Tec Nologic schrieb: > Das Problem an sich war lediglich die Frage wie ich mit C Libs in einem > Cpp Projekt ambesten verfahre. Die Header bekommen ein /#ifdef __cplusplus extern "C"/, das war's. > Speziell Callbackfunktionen aus C Libs > sind ein Problem im Zusammenspiel der beiden Sprachen. Wenn die Callbacks im C++-Modul sind, dann bekommen diese gezielt ein /extern "C"/. > Eben deshalb > erhärtete sich bei mir die Vermutung das die unerwartet große Codesize > aus Problemen zwischen C und C++ herrührt. Wie schon gesagt, mit 99%iger Sicherheit liegt es nicht daran. Tec Nologic schrieb: > welche Flags muss ich nm geben damit der mir die Symboltable lesbar > ausgibt. Bzw kann man die in eine textdatei ausgeben? die Liste ist > ellen lang die nm ausgibt. Einfach umleiten: nm x.elf > x.txt
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.