Tatsächliche Größe des Flashs ATTiny85

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.

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.

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.