Ich weiss dass viele nun versuchen werden mir das auszureden, da die Verwendung der STL auf einem uC bestenfalls fragwürdig ist, hoffe jedoch dass mir trotzdem jemand helfen kann. Im übrigen besteht mein Prof auf der Verwendung der STL Ich Arbeite derzeit mit einem mcb2300 (nxp lpc2388) und einer Yagarto Toolchain. Es ist auch kein Problem C++ Code zu verwenden, Klassen und deren Ableitungen habe ich bereits erfolgreich getestet. Evtl ist es auch eine nur eine Kleinigkeit, aber ich denke es gibt derzeit keinen STL support innerhalb Yagarto? Es gibt zwar eine libstdc++.a allerdings bin ich mir ehrlich gesagt nicht sicher was diese enthält. Einen Header für lists oder maps finde ich innerhalb der Toolchain leider nicht :/ Sind diese Header irgendwie in der C++ Lib versteckt und mir fehlt nur eine entsprechende linker/compiler option? Wenn nicht, was würde zu einem brauchbaren Ergebnis führen, ich denke da beispielsweise an STL port?
:
Verschoben durch Moderator
Die Header heißen nach aktuellem Stand nicht list.h, map.h etc., sondern schlicht list und map. Vielleicht mal danach im Dateisystem suchen? Zum Kompilieren werden diese benötigt, heraus kommt dabei eine sogenannte Objektdatei. Der Linker macht dann daraus (zusammen mit anderen Objektdateien z.B. aus Bibliotheken) das ausführbare Programm. Die libstdc++.a ist eine solche Bibliothek und deutet an, daß es eigentlich möglich sein sollte auf diesem System. Notfalls gibt es diverse Implementierungen der STL, die man sich aus dem Internet holen kann.
Gut zu wissen, hätte ich mir eigentlich denken müssen. Habe sie die ganze Zeit nicht gefunden, da ich explizit nach list.h gesucht habe. Und da ich vergessen hatte das include dir einzugeben hatte ich bei #include <list> auch nur eine unresolved inclusion. Beim durchstöbern von Yagarto ist mir aufgefallen dass es neben list und map, auch stl_list.h und stl_map.h gibt. Sind diese dann die Entsprechungen der "alten" list.h und map.h?
Erstmal entschuldigt bitte den Doppelpost, es ist mir irgendwie nicht möglich meinen eigenen Beitrag zu bearbeiten. Nach dem Einrichten des passenden Include Directories kann ich nun eine Liste im Code erstellen und das ganze auch fehlerfrei kompilieren :) Die Größe meiner Binary geht allerdings von 3kb auf ~65kb (was eigentlich ja nicht sooo schlimm sein sollte bei 512kb flash). Der wirklich störende Punkt ist, dass das Programm nicht auf dem uC läuft. da passiert einfanch gar nichts mehr. Gdb hängt einfach bei continue, hat jemand eine Idee woran so etwas liegen kann?
Thorsten F. schrieb: > Beim durchstöbern von Yagarto ist mir aufgefallen dass es neben list und > map, auch stl_list.h und stl_map.h gibt. Sind diese dann die > Entsprechungen der "alten" list.h und map.h? Schwer zu sagen. Aber das sind ja alles Text-Files. Mach sie auf und sieh nach.
Thorsten F. schrieb: > Nach dem Einrichten des passenden Include Directories kann ich nun eine > Liste im Code erstellen und das ganze auch fehlerfrei kompilieren :) > Die Größe meiner Binary geht allerdings von 3kb auf ~65kb (was > eigentlich ja nicht sooo schlimm sein sollte bei 512kb flash). Eigentlich schon. Dass das list template ein bischen was mit auf die Waage bringt ist ok. Aber 65 kB ist schon ein wenig heftig. > Der wirklich störende Punkt ist, dass das Programm nicht auf dem > uC läuft. da passiert einfanch gar nichts mehr. Programm?
Hier mal meine Main.cpp
1 | #include "LPC23xx.h" |
2 | #include "LCD.h" |
3 | #include "C:\Programme\yagarto\arm-elf\include\c++\4.4.2\list" |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | int main(){ |
10 | |
11 | // std::list<char> testlist; //Diese Zeile macht 63kb aus und führt zum hängen des Boards/Debuggers |
12 | lcd_init(); |
13 | lcd_clear(); |
14 | PINSEL10 = 0; /* Disable ETM interface, enable LEDs */ |
15 | FIO2DIR = 0x000000FF; /* P2.0..7 defined as Outputs */ |
16 | FIO2MASK = 0x00000000; |
17 | FIO2CLR = 0xFF; /* Turn off all LEDs */ |
18 | FIO2SET = (0xFF); /* Turn on requested LEDs */ |
19 | |
20 | |
21 | |
22 | lcd_print ("Base Project"); // Display string on LCD display |
23 | set_cursor (0, 1); // Set cursor position on LCD display |
24 | lcd_print ("stl on mcb2300"); |
25 | |
26 | |
27 | return 0; |
28 | } |
Ich hänge mal sicherheitshalber noch mein makefile sowie das Linkerscript mit an.
Makfile # Optimization level, can be [0, 1, 2, 3, s]. # 0 = turn off optimization. s = optimize for size. # (Note: 3 is not always the best optimization level. See avr-libc FAQ.) #OPT = s OPT = 0 ohne Optimierung OK, dann glaub ich dir, dass da 65kB draus werden. Bei Verwendung der STL ist das Einschalten der Optimierung quasi Pflicht. Probiers aus, geh auf s, der Speicherverbauch sollte eigentlich drastisch sinken. Wenn ja: dann ist das nichts worüber du dir jetzt Gedanken machen müsstest. Der Hänger ist aber blöder. Da weiß ich jetzt auch nicht weiter. Nur dadurch, dass du eine Liste definierst, sollte eigentlich nichts hängen. Versuch mal im Konstruktor der Liste herauszufinden, ob da irgendwelche Dinge dynamisch allokiert werden und ob du Unterstützung für new/delete hast.
Ich gehe schwer davon auss das dort dynamisch Speicher angelegt wird, jedoch werden new und delete unterstützt. Der Tipp mit der Opimierung war auf jeden Fall Gold wert. Die Codegröße ist von 64kb auf 7kb, und erstaunlicherweise funktioniert das Programm nun auch. Das ist irgendwie verwirrend, aber ich bin erstmal happy. Werd die Liste jetzt mal ausgiebiger testen.
NB: absolute Pfade in einem #include sind nicht Sinn der Sache und gelten gemeinhin als zumindest unelegant.
Der absolute Pfad ist mittlerweile aus dem Projekt verschwunden (EXTRAINCDIRS im makefile entsprechend erweitert). Vielen Dank für den Hinweis, ich werde das in Zukunft vermeiden. Mein Vorhaben die Liste zu testen scheiterte bisher leider kläglich, es ist mir zwar möglich eine leere Liste anzulegen, jedoch lässt ein einfaches .push_back() meine Codegröße auf ~64kb anspringen und das Programm hängt wieder (Wieder auch so dass das Debuggen nicht mehr funktioniert) Fehlen mir hier ein paar wichtige Compilerflags?
64 kB als Speichermenge, die man mit 2 Byte adressieren kann, riecht ja danach, daß evtl. Zeiger nur 16 Bit haben und gar nicht mehr geht?
Nunja irgendwie sollte es ja funktionieren, ansonsten ergibt die Implementierung der Liste ja irgendwie keinen Sinn. Stimmt evtl etwas bei der Speicherallokierung nicht? momentan verwende ich vereinfachte Implementierungen von new und delete Ich glaube bei mir ist irgendwas größeres falsch, ich habe beispielsweise das gleiche verhalten (codegröße und debugger) wenn ich beispielsweise die Flag -fno-execptions entferne.
Gibt es ein Problem wenn mit dem interworking bzw dem Thumb instruction set in diesem Zusammenhang? Verwende ich ausschließlich das ARM instructionset wird mein code noch gewaltiger(64kb->~80kb), aber scheint es zu funktionieren.
Bitte 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.