Hallo, ich habe mit dem GCC ein programm mit mehreren Modulen compiliert. Dabei habe ich mit avr-size folgende Ausgabe erhalten: section size addr .text 3006 0 .data 266 8388704 .bss 1296 8388970 .noinit 0 8390266 .eeprom 0 8454144 .stab 7632 0 .stabstr 4576 0 Total 16776 Was besagen mir diese Angaben? Bzw. warum stimmen die nicht mit der map-Datei überein? Dort steht: Memory Configuration Name Origin Length Attributes text 0x00000000 0x00002000 xr data 0x00800060 0x0000ffa0 rw !x eeprom 0x00810000 0x00010000 rw !x default 0x00000000 0xffffffff Was besagt mir bei avr-size die Angabe "addr"? gibt es irgendwo eine Doku zu avr-size? Danke Grüße Andreas
1.) Ist schon x-mal durchgekaut, eine Forumsuche sollte helfen. 2.) Map-Dateien sind IMHO nichts, was der normale Mensch auch nur ansatzweise braucht. Einen Grund siehst du gerade selbst: sie stiften nur Verwirrung. Außerdem sind sie (IMHO) absolut unübersichtlich. Das Ding taugt nur für eins: zum Debuggen des Linkers. Wenn du wissen willst, wo was im Binary ist, guckste in die Symboltabelle (Ausgabe von avr-nm, WinAVR legt IMHO automatisch eine mit der Endung .sym an). 3.) addr ist die Ladeadresse. Dabei hat der EEPROM aus internen Gründen einen Offset von 0x810000, der RAM von 0x800000. Was in welchen sections rauskommt findest du wie gesagt mittels Forumsuche.
Hallo Jörg, erstmal danke für die Antwort. Klar wurde diese Frage schon mehrfach gestellt. Aber meine Suche hat nichts ergeben, da ich ein konkretes Problem habe und erst einmal damit feststellen wollte, ob ich das richtig verstanden habe. Die Größe passt auch und habe ich mir so gedacht. Mein Problem liegt hierin: .data 266 8388704 Ich habe ein Programm für den Atmega162 erstellt. Im AVR-Studio funktioniert es einwandfrei. In der Hardware läuft es nur mit externem Ram. Wenn ich den entferne und auch MCUCR nicht setze, bin ich der Meinung, dass bei 266 Bytes das mit dem internen Ram gehen sollte. Geht aber eben nicht. Daher war meine Vermutung, dass mit addr irgendwas in Richtung einer Startadresse angegeben wird. Bei der Ursachenforschung versucht man ja sich überall dran festzuklammern. Ich hatte z.B. eine boolsche Variable, bei der weder der Vergleich auf TRUE noch auf FALSE erkannt wurde sondern immer in den else-Zweig gesprungen wurde. (if variable == true/false){...}else {...} Mir kommt gerade der Einfall, ist .data überhaupt der Ram? Wo finde ich eine Doku? Weder die Forensuche noch google hat mir was vernünftiges geliefert. Hoffe habe mich verständlich ausgedrückt.
Hmm, beim neuen WinAVR hat doch Eric jetzt einen Script beigelegt, der das etwas netter ausgibt, oder (einschließlich Prozent ,,Füllstand'')? Kurz: .text + .data = ROM-Verbrauch, .data + .bss [+ .noinit] = statischer RAM-Verbrauch, da kommt aber noch der Stack (Return-Stack und auto-Variablen) hinzu. Wenn du wirklich nur das externe RAM-Setup änderst, ohne irgendwelche -T-Optionen, um das Datensegment zu schieben, dann klingt das aber nach einem Hardwareproblem -- deine Variablen, Stack etc. liegen nämlich so oder so immer im internen RAM dann. Boolsche Variablen vergleicht man nicht auf true oder false, sondern benutzt sie direkt im Steuerausdruck: if (booleanvar) { ... } else { ... } Da sie in aller Regel nicht als 1-bit-Variablen (sinnvoll) realisiert werden können, können sie eben auch Werte verschieden von true oder false annehmen. Für einen ,echten' Boolean, also eine Variable vom Type "bool" gemäß <stdbool.h> sollte das nicht passieren, wenn der Compiler ihr die Werte zuweist, aber du drückst dich ziemlich verwaschen aus (selbst die Groß- und Kleinschreibung stimmt ja nicht, obwohl C darin bekanntlich unterscheidet).
Hallo Jörg, sorry für das verwaschene. Waren gestern abend schon 2 Gläser Wein und wollte noch schnell zurück schreiben. Ich benutze fertige Programm-Module eine Multitasking-Systems (ucos-II) Dort steht irgendwo: #define TRUE 1 #define FALSE 0 In dem Programm steht dann irgendwo if(variable == FALSE). Ich möchte in diesem Modulen auch nicht änderen, da diese Standard sind und, wie auf der ucos-Seite zu sehen, schon für etliche Controller eingesetzt wurden. Auch für einen AVR mit dem GCC (weiss im Moment nicht für welchen genau). Geändert (-T) habe ich nichts. Ich benutze das Standard-Makefile, dass beim neusten winavr dabei ist: # based on # WinAVR Sample makefile written by Eric B. Weddington, Jörg Wunsch, et al. Zum testen habe ich im Hauptprogramm lediglich diese Zeile: MCUCR = (1<<SRE) | (1<<SRW10); auskommentiert und den Ram aus der Hardware (Original STK200) entfernt. Lese gerade nochmals: "Kurz: .text + .data = ROM-Verbrauch, .data + .bss [+ .noinit] = statischer RAM-Verbrauch" Das kann nicht funktionieren. Der ATMega162 hat 1K internen RAM. bss= 1296 ist (ohne Stack) schon über 1K. Kann also nur mit externem Ram laufen. Aber was ich nicht daran verstehe, wieso wird .data sowohl für Ram als auch Rom verwendet? Was für ein Script von Eric meinst Du? Habe nichts gefunden. Vielleicht wäre es mir ja damit direkt aufgefallen. Danke Andreas
Jörg meint das Programm/Skript, welches diese Ausgabe bei der Compilation ausspuckt: AVR Memory Usage: ----------------- Device: atmega128 Program: 13512 bytes (10.3% Full) (.text + .data + .bootloader) Data: 2222 bytes (54.2% Full) (.data + .bss + .noinit)
Danke Patrick, da ich selbst kein Windows habe, wusste ich nicht, wie's genau heißt. > Das kann nicht funktionieren. Der ATMega162 hat 1K internen RAM. > bss= 1296 ist (ohne Stack) schon über 1K. Umm, ja. Dann solltest du aber mit dem externen RAM auch noch die Optionen feilen (z. B. via Mfile), damit der auch benutzt wird. > Aber was ich nicht daran verstehe, wieso wird .data sowohl für Ram > als auch Rom verwendet? .data enthält die initialiserten Variablen. Da Telepathie als Möglichkeit für eine korrekte Initialisierung ausfällt :-) erfolgt diese über den ROM (indem der Inhalt von .data hinter .text im ROM steht und vom Startup-Code in den RAM kopiert wird). Schade, dass ucos so einen Schwachsinn im Code hat. :-(
Das Progrämmchen hat nur ein kleines Problem bei Verwendung von externem SRAM (Stack intern, alles andere extern): AVR Memory Usage: ----------------- Device: atmega128 Program: 32646 bytes (24.9% Full) (.text + .data + .bootloader) Data: 11692 bytes (285.4% Full) (.data + .bss + .noinit)
Danke Euch beiden. Allerdings finde ich dieses Programm/Script nirgendwo. Ist allerdings auch jetzt nicht mehr so wichtig. Werde mich mal nach einer Doku zu avr-size auf die Suche machen. Grüße Andreas
Wenn du das Programm nicht findest, hast du wohl nicht die neueste WinAVR-Version. ;-) Patrick, melde das mal dem Eric als Bug.
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.