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
0s ist klar. Aber wo kommt -ffunction-sections und --gc-sections hin? Danke für den Tipp!
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?
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.
Tja, schade! Vielen Dank für die Hilfe und den Tipp mit der anderen Lib! Gruß Jansus
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.
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...
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.