Teile der STL benutzen auf arm7 mittels Yagarto

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.