Hi, laut TRM hat der ATTiny85 eine Flash-Größe von 8K (=8192 Bytes). Lustigerweise meckert der AVR-GCC bei einer Codegröße von 8194 Bytes noch nicht, der beschwert sich erst bei ca. 1900 Bytes darüber, dass der Code zu groß geworden ist. Das wirft jetzt die Frage auf: hat der ATTiny85 tatsächlich etwas mehr Flash und wenn ja wie viel? Danke!
Wonach gehst Du? Nach der Codegröße im .map-File (korrekt), oder nach der Größe des .coff-Files (inkorrekt, enthält noch Debugsymbole etc)? fchk
Ich gehe nach der Ausgabe von avr-size:
1 | avr-size main.hex |
2 | text data bss dec hex filename |
3 | 0 8196 0 8196 2004 main.hex |
Sortland schrieb: > laut TRM hat der ATTiny85 eine Flash-Größe von 8K (=8192 Bytes). Hat er. > Lustigerweise meckert der AVR-GCC bei einer Codegröße von 8194 Bytes > noch nicht, der beschwert sich erst bei ca. 1900 Bytes darüber, dass der > Code zu groß geworden ist. Dann taugt er nix. Oder du verstehst nicht, was er dir sagt. Lustigerweise kann hier nicht mal der AVR-Assembler wirklich punkten, auch der läßt sich relativ leicht verarschen, was seine Größenprüfungen von Speicherbereichen angeht. Er beherrscht nämlich angeblich Sachen wie ".overlap", tut das aber nicht wirklich. Zumindest die IDE kommt damit nicht wirklich klar, sondern addiert überlappende Bereiche treudoof auf, so oft man sie erzeugt und das u.U. sogar gleich doppelt, nämlich einmal als Flash-Daten und gleich nochmal als Code... Also Fazit: unabhängig von der Sprache gibt letzte Gewissheit nur die eigene Kompetenz. Mit Werkzeugfehlern ist immer zu rechnen. Und nach dem Komplexitätsprinzip natürlich: Je aufwendiger das Werkzeug, desto wahrscheinlicher sind Fehler darin. Da ist ein Assembler also gegenüber einem C-Compiler ab Start erstmal sehr viel vertrauenswürdiger. Natürlich ist das nur die Anfangswahrscheinlichkeit für Fehler. Wenn der Assembler nur lausig gepflegt wird, der C-Compiler hingegen sehr gut, dann können sich die Verhältnisse natürlich auch sehr schnell umkehren.
In der avrdude.conf steht klar drin, dass der Flash Speicher 8192 Bytes groß ist.
Stefan U. schrieb: > In der avrdude.conf steht klar drin, dass der Flash Speicher 8192 Bytes > groß ist. Ich würde da zuallererst und ausschließlich im Datenblatt des Controllers nachsehen...
Bei mir erzeugt der Compiler auch öfters zu großen Code. Ich merke das meistens erst, wenn ich avrdude benutze. Deswegen dachte ich bislang, dass der Compiler die Größe gar nicht überprüft.
Stefan U. schrieb: > Deswegen dachte ich bislang, dass der Compiler die Größe gar nicht > überprüft. Im Linkerscript ist die Größe jeder Section angegeben, der Linker (nicht der Compiler) sollte einen Fehler werfen.
Sortland schrieb: > Lustigerweise meckert der AVR-GCC bei einer Codegröße von 8194 Bytes > noch nicht, der beschwert sich erst bei ca. 1900 Bytes darüber, dass der > Code zu groß geworden ist Copy&Paste mal die Fehlermeldung. Vermutlich besagt die Meldung nur, daß ein RJMP/RCALL zu weit geht.
Sortland schrieb: > Ich gehe nach der Ausgabe von avr-size: > >
1 | > avr-size main.hex |
2 | > text data bss dec hex filename |
3 | > 0 8196 0 8196 2004 main.hex |
4 | >
|
"data" ist das Datensegment (genauer gesagt: der Teil des Datensegments
in dem initialisierte Variablen liegen). In den Flash muß Programmcode
(Segment "text") und Datensegment ("data", s.o.) passen.
Allerdings ist obiges sowieso Blödsinn. Das Textsegment kann keine Größe
0 haben. Also nicht für ein Programm das auch was tut.
Ach so: avr-size wendet man nicht auf das Hexfile an, sondern auf das
ELF-File (hier wohl main.elf).
:
Bearbeitet durch User
Axel S. schrieb: > Allerdings ist obiges sowieso Blödsinn. Das Textsegment kann keine Größe > 0 haben. Also nicht für ein Programm das auch was tut. Das .hex-File hat nur data und keinen text. text hat das elf-File ;) Hier ein Beispiel aus einem aktuellen Programm:
1 | rescuePod:firmware michael$ avr-size main.hex |
2 | text data bss dec hex filename |
3 | 0 6472 0 6472 1948 main.hex |
4 | rescuePod:firmware michael$ avr-size main.elf |
5 | text data bss dec hex filename |
6 | 6050 422 2 6474 194a main.elf |
:
Bearbeitet durch User
Michael K. schrieb: > Das .hex-File hat nur data und keinen text. text hat das elf-File ;) > Hier ein Beispiel aus einem aktuellen Programm: >
1 | > rescuePod:firmware michael$ avr-size main.hex |
2 | > text data bss dec hex filename |
3 | > 0 6472 0 6472 1948 main.hex |
4 | > rescuePod:firmware michael$ avr-size main.elf |
5 | > text data bss dec hex filename |
6 | > 6050 422 2 6474 194a main.elf |
7 | > |
Hmm. Faszinierend daß avr-size überhaupt ein .hex File akzeptiert. Wo es doch offensichtlich nur Unsinn daraus extrahiert. Der Denkfehler des TE ist jetzt jedenfalls klar: avr-size muß auf das .elf File angewendet werden, wenn man sehen will wie voll ein Programm den Flash bzw. RAM des µC macht.
Axel S. schrieb: > Michael K. schrieb: > >> Das .hex-File hat nur data und keinen text. text hat das elf-File ;) >> Hier ein Beispiel aus einem aktuellen Programm: >>
1 | >> rescuePod:firmware michael$ avr-size main.hex |
2 | >> text data bss dec hex filename |
3 | >> 0 6472 0 6472 1948 main.hex |
4 | >> rescuePod:firmware michael$ avr-size main.elf |
5 | >> text data bss dec hex filename |
6 | >> 6050 422 2 6474 194a main.elf |
7 | >> |
> > Hmm. Faszinierend daß avr-size überhaupt ein .hex File akzeptiert. > Wo es doch offensichtlich nur Unsinn daraus extrahiert. Tut er nicht. Die Ergebnisse sind völlig gleichwertig. Man muß einfach nur genug Grips in der Birne haben, um sie korrekt bewerten zu können. Die Sache ist einfach die, daß im Hexfile der Unterschied zwischen Code und Daten verloren geht, auch Code wird zu Daten. Und tatsächlich ist Code auch nichts anderes als Daten, eben welche, die die Codewörter eines Maschinenprogramms enthalten. Es wird also die Summe von Code und Daten in den Flash geschrieben. Paßt auch: 6050+422=6472. Bleiben die zwei Bytes BSS. Das ist (uninitialisiertes) RAM! Das wird nicht in den Flash geschrieben und dementsprechend taucht es im Hexfile auch nicht auf, denn das enthält nur das, was tatsächlich in den Flash geschrieben wird.
Danke für die Erklärung, hat mir sehr geholfen. Auch wenn ich die Frage nicht gestellt hatte.
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.