Tach auch,
ich arbeite seit ca. 2 Jahren mit dem SDK "Precision32" von SILABS für
einen ARM3-(CORTEX-M3)-Prozessor "SIM3U166".
Das funktioniert soweit ganz gut, aber ich vermisse so ein paar
Tools/Funktionen, die es bei anderen modernen Compilern gibt (evtl. habe
ich es nur nicht gefunden?).
Bei einem Projekt komme ich mittlerweile an die Resourcen-Grenzen (RAM,
32kB) und gelegentliche "merkwürdige" Effekte lassen mich befürchten,
dass irgendwo im RAM (HEAP und STACK) sich etwas überschneidet.
Zusätzlich verwende ich zur Laufzeit die Funktionen "malloc" und "free".
Gibt es Möglichkeiten bei dieser GCC-Variante ("arm-none-eabi-gcc"
zusammen mit REDLIB) sowas wie:
- Stack-Überlauf-Schutz (temporär wegen Performance) zu aktivieren?
- detaillierte Auflistung, wie groß der maximal Stack-Bedarf ist?
- andere Hilfemittel zum Aufspüren o.a. "Fehler"?
Beim guten alten 8051 (KEIL-Compiler) gab es das auch nicht, aber die
MAP-Datei war m.E. schon recht ausführlich und hat mir oft "den Weg
gezeigt", um Fehler bei der Speicher-Aufteilung zu finden. Der Linker
hat auch sofort gemeckert, wenn zuwenig Speicher (idata) verfügbar ist.
Beim ARM3 habe ich mir zum Testen mal die höchste Adresse, die beim
"malloc" auftritt, ausgegeben, so dass ich ungefähr sehe, was da
dynamisch "verbraucht" wird. Aber so richtig aussagekräftig scheint mir
das nicht zu sein.
Viele Grüße
Peter
Peter D. schrieb: > - Stack-Überlauf-Schutz (temporär wegen Performance) zu aktivieren? Könnte man eventuell durch geschickte Verwendung der MPU hinbekommen. > - detaillierte Auflistung, wie groß der maximal Stack-Bedarf ist? Geht nicht ohne weiteres, da der Cortex M3 verschachtelte Interrupts kennt, und in den Handlern auch weitere Funktionen aufrufen kann. Das kann den Stack Bedarf ganz schön in die Höhe treiben. > Zusätzlich verwende ich zur Laufzeit die Funktionen "malloc" und "free". Das sollte man auf einem µC besser bleiben lassen. Meistens sind statisch allokierte Puffer besser geeignet. Dynamischer Heap hat außerdem einen Overhead, den man bei 32kB RAM nicht wirklich haben will. Wenn das RAM Problem wirklich sooo groß wird: Schau Dir mal die EFM32GG Serie, ebenfalls von Silabs, an. Die haben 128 KB RAM und bis 1 MB Flash on Chip.
Hallo Jim, danke für deine schnelle Antwort. "malloc" setze ich auch nur ein, da ich Texte (verschiedener Länge) von einer SD-Karte laden und dann im RAM ablegen muss. Das mache ich auch nur einmal beim Start des µC, so dass ein "dauerndes" umallokieren nicht stattfinden sollte. Wer ein bessere Idee als "malloc" hat, bitte melden! Anderer Chip ist immer eine gute Idee, wenn man noch die Wahl hat. In meinem Fall exisitiert die Schaltung wie sie ist! Den µC, den Du vorgeschlagen hast, ist auch für ein Redesign im Gespräch. Aber alles noch Zukunfts-Musik... Viele Grüße Peter
Ach ja, noch einen weiteren "Speicherfresser" habe ich gefunden und noch nicht beheben können (z.B. mit pragmas). Beispiel: C-Datei:
1 | static char c1; |
2 | static char c2; |
3 | static char c3; |
4 | static char c4; |
5 | static char c5; |
6 | static char c6; |
7 | static char c7; |
8 | static char c8; |
Schaue ich dann in der MAP-Datei nach (editiertes Beispiel):
1 | .bss.c1 0x200011cf 0x1 ./src/c.o |
2 | .bss.c2 0x200011d0 0x1 ./src/c.o |
3 | *fill* 0x200011d1 0x1 00 |
4 | .bss.c3 0x200011d2 0x1 ./src/c.o |
5 | .bss.c4 0x200011d3 0x1 ./src/c.o |
Des Weiteren sortiert der Linker andere globale Variablen zwischen die 8 o.a. Beispiel-Variablen (c1..c8). Wieso macht der das? Und wie schließt man diese Lücken? Das ist zwar jetzt keine Riesenmenge an RAM, aber es ist schade drum ;) Grüße Peter
Peter D. schrieb: > Das ist zwar jetzt keine Riesenmenge an RAM, aber es ist schade drum ;) Und warum müllst du dir dann den RAM mit Texten von einer SD-Karte zu? So eine Karte ist doch schnell genug, um Texte nur bei Bedarf von dort zu holen. Alternativ pack deine Texte in den Flash, da kosten sie wenigstens keinen RAM. W.S.
W.S. schrieb: > Peter D. schrieb: >> Das ist zwar jetzt keine Riesenmenge an RAM, aber es ist schade drum ;) > > Und warum müllst du dir dann den RAM mit Texten von einer SD-Karte zu? > So eine Karte ist doch schnell genug, um Texte nur bei Bedarf von dort > zu holen. Alternativ pack deine Texte in den Flash, da kosten sie > wenigstens keinen RAM. > > W.S. Hallo W.S., noch ist es nicht notwendig gewesen. Im Moment reicht das RAM ja noch, ich möchte halt nur wissen, wo es bleibt und wie man es optimieren kann. Von der SD-Karte laden geht nur solange gut, solange die SD-Karte einwandfrei funktioniert. Es handelt sich dabei um Texte, die auf einem Display dargestellt werden und da möchte ich nicht, dass es "ruckelt", wenn irgendwelche Seiten mit Text gefüllt werden. Flash ist leider auch schon ziemlich voll. Grüße Peter
Ruckelt? Betreibst du das Teil mit men 32kHz Uhrenquarz-Takt? Peter D. schrieb: > Wer ein bessere Idee als "malloc" hat, bitte melden! So, du lädtst diesen ominösen Text einmal am Start in den RAM. Wozu brauchst du für diesen einmaligen Vorgang dann malloc und Konsorten? Stelle einfach fest, wie groß dein Text ist und fertig. Alternativ verfrachte ihn in den Flash. Ich suche jetzt nicht nach deinem µC im Inet, um herauszukriegen, wieviel Flash er hat, aber bei 32 K RAM schätze ich mal kühn, daß er wohl jenseits von 256 K Flash liegen dürfte. Und wenn er von deinem Programm schon "ziemlich voll" ist, dann überlege dir erstmal, was du dort an überflüssigem Ballast alles drin hast. Dusselige Pseudo-Treiber wie die ST-Lib bei ST? Oder uneffektiv codierte Fonts? Oder noch uneffektiver codierte Grafiken? Oder sowas wie zlib? Geh einfach mal mit der Machete durch deine Zubehör-Quellen. W.S.
Hallo W.S., > Peter D. schrieb: >> Wer ein bessere Idee als "malloc" hat, bitte melden! > > So, du lädtst diesen ominösen Text einmal am Start in den RAM. Wozu > brauchst du für diesen einmaligen Vorgang dann malloc und Konsorten? > Stelle einfach fest, wie groß dein Text ist und fertig. Alternativ > verfrachte ihn in den Flash. Ich suche jetzt nicht nach deinem µC im > Inet, um herauszukriegen, wieviel Flash er hat, aber bei 32 K RAM > schätze ich mal kühn, daß er wohl jenseits von 256 K Flash liegen > dürfte. er hat 256k, wovon aber schon 128 für die Applikation benötigt wird. Etwas Reserve hatte ich bei Vergrößerung der Applikation eingeplant, so dass ich aktuell nur 64k für Daten verwende und die sind auch schon zu 80% belegt. Da könnte ich aber für die Texte noch was abknappsen, was ich jetzt auch machen werde... Grüße Peter
Thread beobachten
Seitenaufteilung abschaltenBitte 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.