EFSL Programmgröße LPC2148

Jansus Gast #715284
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jansus Gast #715493
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Andreas S. Admin Persönliche Seite #715496
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Martin T. Moderator Persönliche Seite #715530
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jansus Gast #715772
Lesenswert?
• ▲
▼ 
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...
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren