EFSL Programmgröße LPC2148

[Jansus (Gast)]

Hallo!

Ich verwende Yagarto, nen LPC2148, Gnu-Compiler...
Ich möchte gerne die EFSL verwenden und habe mir dazu die Beispiele von 
Martin Thomas angesehen.
Daraufhin habe ich mir die Lib (*.a) erstellt und Teile des beiliegenden 
Beispielprogramms abgschrieben.
Prinzipiell hat alles problemlos geklappt. Nur leider ist die hex-Datei, 
die ich ausgespuckt bekomme unheimlich groß (ca.50K). Logischerweise ist 
mit meinem RAM, in dem ich debugge, bald Schluss. Daher würde es mich 
interessieren, ob jemand eine Lösung kennt. Also, wie ich das hex-File 
kleiner bekomme, denn schließlich möchte ich ja schon etwas komplexeres 
als das EFSL-Beispiel erzeugen.
Schonmals vielen Dank!

Gruß
Jansus

[Andreas S. (andreas) (Admin)]

-Os
-ffunction-sections und --gc-sections

[Jansus (Gast)]

0s ist klar. Aber wo kommt -ffunction-sections und --gc-sections hin? 
Danke für den Tipp!

[Jansus (Gast)]

OK. Habe die Flags hinzugefügt. Bekam prompt ne Fehlermeldung.
Habe daraufhin gelesen, dass ich mein doch recht einfach gestricktes 
Linkerskript anpassen muss.
Habe dann  aus *(.text) -->
 *(.text .text.* .gnu.linkonce.t.*)
gemacht, entsprechend auch mit data und bss.
Compilieren klappt ohne Fehlermeldung. Leider hat sich aber die Größe 
meines hex-files nicht wirklich verkleinert (jetzt etwa 46K).

Habe ich vielleicht noch etwas anzupassen? Oder was vergessen?

[Andreas S. (andreas) (Admin)]

Hab das gerade hier zusammengefasst: [[GCC: unbenutzte Funktionen 
entfernen]]

Wenn sich dadurch nichts an der Größe ändert, dann werden die Funktionen 
wohl wirklich alle benötigt. Schau mal die .map-Datei was genau da so 
viel Platz braucht, vielleicht ist ein printf mit Floating 
Point-Unterstützung dabei oder ähnliches. Falls die EFSL wirklich 
alleine so viel braucht gäbe es eine kleinere Alternative bei 
elm-chan.org.

[Jansus (Gast)]

Tja, schade!
Vielen Dank für die Hilfe und den Tipp mit der anderen Lib!

Gruß
Jansus

[Martin T. (mthomas) (Moderator)]

50kB ist tatsächlich etwas groß. Bei einer Beispielanwendung (nicht nur 
die Library) "hier" ist .text ca. 23kByte für arm-mode und ca. 16kB für 
thumb/thumb-interwork. Jeweils mit "unused code removal" aber selbst mit 
"unused code" wird das binary hier kaum 1kB größer. Für debugging im RAM 
muss man noch die bss-section berücksichtigen, da die efsl darin die 
Arrays für die Caches anlegt. Aber selbst damit sollten das LPC2148 RAM 
reichen. Vermute wie Andreas, das da wohl irgendwie stdio reingerutscht 
ist. Was steht im map-file irgendwas mit printf oder scanf? Was gibt nm 
als größte Speicherfresser aus?

Chan's Library ist sicher eine gute Wahl, nicht ganz so ausgeklügeltes 
Chache-Management wie die efsl aber dafür in Sachen Codegröße 
wahrscheinlich kaum noch zu optimieren.

[Jansus (Gast)]

Die 50K sind ja das hex-file. Laut map-file ist .text 16K und .bss ca. 
7K. Hatte gehofft, dass es irgendwie kleiner geht. Werde also die andere 
Lib testen.
Von printf und scanf ist weit und breit nichts zu sehen.
Mein Problem gestaltet sich dermaßen, dass der µC abstürzt sobald ich 
weiteren Code hinzufüge (der aber separat schon läuft). Hatte 
angenommen, dass der RAM nicht ausreicht...
Bin ratlos...