Hallo, kennt sich jemand mit der Speicherverwaltung des avr-gcc aus? Problem: Mein Programm verwendet einige statische globale Variablen, dynamische Speicherallozierung mit malloc() und Rekursion wird nicht verwendet. Die größte globale statische Variable ist ein Puffer der Form uint16_t buf[2048]; also 4096 Byte, dazu kommen noch einige dutzend Byte für andere Variablen. Ich hatte mir bisher keine großen Gedanken darüber gemacht, denn mein AT90USB soll 8kByte RAM haben, sollte also locker reichen. Seit gestern funktioniert mein Programm nun aber nicht mehr. Mache ich den Puffer kleiner geht es aber wieder. Ich habe den Eindruck, dass der Puffer in einen nicht existierenden RAM-Bereich gerutscht ist -- vielleicht weil ich in den letzten Tagen ein paar kleinere Variablen hinzugefügt hatte. Hier ist die Ausgabe von avr-size und avr-nm -n stefan@AMD64X2 ~/AT90USB $ avr-size SUDD.elf text data bss dec hex filename 6216 5178 4109 15503 3c8f SUDD.elf 0000000000801266 D USB_Interfaces 000000000080153a B __bss_start 000000000080153a D __data_end 000000000080153a D _edata 000000000080153a B UsbAllocatedEPs 000000000080153b B RemoteWakeupActive 000000000080153c B UsbDevConfValue 000000000080153d B SamplesToRead 000000000080153f B Overflow 0000000000801540 B cnt 0000000000801541 B w 0000000000801543 B r 0000000000801545 B RB_Entries 0000000000801547 B buf 0000000000802547 B __bss_end 0000000000802547 ? _end 0000000000810000 ? __eeprom_end Gruß Stefan Salewski
DATA 5178 + BSS 4109 = 9287 9287 + Stack ? > RAM 8K (8192) Abspecken!
Oh ja, der data Bereich belegt ja auch RAM -- da hatte ich im Moment nicht dran gedacht. Ich hatte in den letzten Tagen noch einige Textausgaben fürs Debugging hinzugefügt, dadurch ist das data Segment gewachsen. Kein Problem, denn die Debugging-Textausgaben fliegen beim endgültigen Programm durch bedingte Compilierung eh raus. Aber dass avr-gcc keine Warnung rausgibt ist mal wieder typisch C: Entweder das Programm macht was es soll, oder eben irgendetwas anderes. Gruß Stefan Salewski
Stefan Salewski wrote: > Aber dass > avr-gcc keine Warnung rausgibt ist mal wieder typisch C: Entweder das > Programm macht was es soll, oder eben irgendetwas anderes. Nein, das hat überhaupt nichts mit "typisch C" zu tun. Es ist ein Dreckeffekt der recht groben Klassifizierung in CPU-Modelle, die für den AVR-GCC benutzt worden ist Damit nicht für jeden neuen AVR erneut alle Linkerscripts kopiert werden müssen und jeder seine eigene Kopie der Bibliothek bekommt, kennt der Linker (der erst könnte sich beklagen, der Compiler weiß noch gar nichts davon) lediglich die absoluten Maximalgrößen der einzelnen Speicherbereiche. Das wäre für dich 64 KiB für den RAM, und die hast du noch nicht überschritten. Kommt übrigens in deinem ganz speziellen Fall noch hinzu, dass du potenziell ja auch externen RAM dran haben kannst, damit sind die 64 KiB Obergrenze ja bei dir sogar gerechtfertigt. Schließlich und letztlich: die Warnung des Linkers würde dir gar nichts nützen. Sie erfolgt nämlich erst, wenn die statische RAM-Belegung zu groß wird, aber du hast auch noch dynamischen RAM, den du brauchst: für den Stack, der beim GCC sowohl Return- als auch Datenstack zugleich ist. Und dessen Größe kann dir kein Linker ermitteln, da sie vom Laufzeitverhalten der Applikation abhängt. Man sollte also hin und wieder mal ein Auge auf seinen Speicherverbrauch haben. Für Debugstrings empfiehlt es sich, sie einfach von vornherein in den ROM zu legen.
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.