mikrocontroller.net

Forum: Compiler & IDEs Teile der STL benutzen auf arm7 mittels Yagarto


Autor: Thorsten F. (thorstenf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thorsten F. (thorstenf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thorsten F. (thorstenf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thorsten F. (thorstenf)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal meine Main.cpp
#include "LPC23xx.h"
#include "LCD.h"
#include "C:\Programme\yagarto\arm-elf\include\c++\4.4.2\list"





int main(){

//    std::list<char> testlist;    //Diese Zeile macht 63kb aus und führt zum hängen des Boards/Debuggers
    lcd_init();
    lcd_clear();
    PINSEL10 = 0;                         /* Disable ETM interface, enable LEDs */
    FIO2DIR  = 0x000000FF;                /* P2.0..7 defined as Outputs         */
    FIO2MASK = 0x00000000;
    FIO2CLR = 0xFF;                       /* Turn off all LEDs                  */
    FIO2SET = (0xFF);                 /* Turn on requested LEDs             */



    lcd_print ("Base Project");                 // Display string on LCD display
    set_cursor (0, 1);                              // Set cursor position on LCD display
    lcd_print ("stl on mcb2300");


  return 0;
}

Ich hänge mal sicherheitshalber noch mein makefile sowie das 
Linkerscript mit an.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thorsten F. (thorstenf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NB: absolute Pfade in einem #include sind nicht Sinn der Sache
und gelten gemeinhin als zumindest unelegant.

Autor: Thorsten F. (thorstenf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thorsten F. (thorstenf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thorsten F. (thorstenf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.