ATtiny13 und Konstanten vs. Variablen.

[Ronny G. (mogel)]

Moin,

ich habe auf meinem STK600 ein ATtiny13 stecken. Dazu folgendes 
Programm:

volatile uint8_t pinmask = 0x55;

int main(void)
{
  DDRB = 0xff;
  
  //while(1 != 0) PORTB = pinmask;
  while(1 != 0) PORTB = 0x55;
}

Verwende ich die Variable "pinmask" (soll später im Timer geändert 
werden), werden entweder alls LED auf 1 gesetzt oder auf 0 (meistens auf 
1). Verwende ich die Konstante, funktioniert es.

Kann mir mal bitte jemand sagen was da schief läuft?

mfg, mogel

[Thomas E. (thomase)]

Ronny G. schrieb:
> Kann mir mal bitte jemand sagen was da schief läuft?

Wahrscheinlich kompilierst du mit der Controllereinstellung für einen 
Atmega. Das Programm kommt zwar auch nicht dort zum Laufen, wo es 
normalerweise bei einem Attiny13 laufen sollte, da es aber kurz ist, 
passt es trotzdem noch rein.
Etwas anderes ist aber der RAM. Bei den Atmegas gibt es den Extended 
I/O-Bereich. Der ist fast dreimal so gross, wie das Daten-RAM des 13er. 
Danach kommt dann der Daten-RAM. Damit käme die Variable ungefähr 4,3mm 
neben dem Gehäuse deines Attiny zu liegen.

mfg.

[Ronny G. (mogel)]

ich habe jetzt nochmal die Einstellungen geprüft (Atmel Studio). Das 
Programm wird direkt für den ATtiny13 compiliert.

[Bernd K. (prof7bit)]

Ronny G. schrieb:

> Kann mir mal bitte jemand sagen was da schief läuft?

Zeig mal die .lss Datei die erzeugt wird

[Thomas E. (thomase)]

Bernd K. schrieb:
> Zeig mal die .lss Datei die erzeugt wird

Beide .lss und das .c

mfg.

[Bernd K. (prof7bit)]

Klingt als würde er die globale Variable nicht initialisieren. Das wäre 
ein compiler bug.

Möglicherweise macht der Optimizer auch eine stillschweigend eine 
Registervariable draus, die kann man aber nicht mit einem Initializer 
automatisch initialisieren, vielleicht fällt das dann versehentlich 
unter den Tisch. Die .lss wäre wirklich aufschlussreich.

[Dieter F. (Gast)]

Was passiert, sieht man hier. Warum es passiert weiß ich leider nicht 
...

volatile uint8_t pinmask = 0x55;

int main(void)
{
  DDRB = 0xff;
  38:  8f ef         ldi  r24, 0xFF  ; 255
  3a:  87 bb         out  0x17, r24  ; 23
  
  while(1 != 0) PORTB = pinmask;
  3c:  80 91 60 00   lds  r24, 0x0060
  40:  88 bb         out  0x18, r24  ; 24
  42:  fc cf         rjmp  .-8        ; 0x3c <main+0x4>

00000044 <_exit>:
  44:  f8 94         cli

00000046 <__stop_program>:
  46:  ff cf         rjmp  .-2        ; 0x46 <__stop_program>



volatile uint8_t pinmask = 0x55;

int main(void)
{
  DDRB = 0xff;
  38:  8f ef         ldi  r24, 0xFF  ; 255
  3a:  87 bb         out  0x17, r24  ; 23
  
  //while(1 != 0) PORTB = pinmask;
  while(1 != 0) PORTB = 0x55;
  3c:  85 e5         ldi  r24, 0x55  ; 85
  3e:  88 bb         out  0x18, r24  ; 24
  40:  fe cf         rjmp  .-4        ; 0x3e <__SP_L__+0x1>

00000042 <_exit>:
  42:  f8 94         cli

00000044 <__stop_program>:
  44:  ff cf         rjmp  .-2        ; 0x44 <__stop_program>

[Bernd K. (prof7bit)]

Dieter Frohnapfel schrieb:
> volatile uint8_t pinmask = 0x55;
>
> int main(void)
> {
>   DDRB = 0xff;
>   38:  8f ef         ldi  r24, 0xFF  ; 255
>   3a:  87 bb         out  0x17, r24  ; 23
>
>   while(1 != 0) PORTB = pinmask;
>   3c:  80 91 60 00   lds  r24, 0x0060
>   40:  88 bb         out  0x18, r24  ; 24
>   42:  fc cf         rjmp  .-8        ; 0x3c <main+0x4>
>
> 00000044 <_exit>:
>   44:  f8 94         cli
>
> 00000046 <__stop_program>:
>   46:  ff cf         rjmp  .-2        ; 0x46 <__stop_program>



Wo ist der Teil der die Variable initialisiert, das volatile uint8_t 
pinmask = 0x55; das suche ich:

sts  0x0060, ...

fehlt, oder ist das irgendwo weiter oben? Poste doch mal die ganze Datei 
und nicht nur einen winzigen Schnipsel.

[Dieter F. (Gast)]

O.K., hier komplett ...

Attiny13 Test.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000048  00000000  00000000  00000074  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .data         00000002  00800060  00000048  000000bc  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  2 .stab         000006b4  00000000  00000000  000000c0  2**2
                  CONTENTS, READONLY, DEBUGGING
  3 .stabstr      00000097  00000000  00000000  00000774  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .comment      0000002f  00000000  00000000  0000080b  2**0
                  CONTENTS, READONLY
  5 .debug_aranges 00000020  00000000  00000000  0000083a  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   0000009e  00000000  00000000  0000085a  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_abbrev 0000006b  00000000  00000000  000008f8  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_line   000000de  00000000  00000000  00000963  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_frame  00000024  00000000  00000000  00000a44  2**2
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    000000b6  00000000  00000000  00000a68  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_ranges 00000010  00000000  00000000  00000b1e  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  09 c0         rjmp  .+18       ; 0x14 <__ctors_end>
   2:  19 c0         rjmp  .+50       ; 0x36 <__bad_interrupt>
   4:  18 c0         rjmp  .+48       ; 0x36 <__bad_interrupt>
   6:  17 c0         rjmp  .+46       ; 0x36 <__bad_interrupt>
   8:  16 c0         rjmp  .+44       ; 0x36 <__bad_interrupt>
   a:  15 c0         rjmp  .+42       ; 0x36 <__bad_interrupt>
   c:  14 c0         rjmp  .+40       ; 0x36 <__bad_interrupt>
   e:  13 c0         rjmp  .+38       ; 0x36 <__bad_interrupt>
  10:  12 c0         rjmp  .+36       ; 0x36 <__bad_interrupt>
  12:  11 c0         rjmp  .+34       ; 0x36 <__bad_interrupt>

00000014 <__ctors_end>:
  14:  11 24         eor  r1, r1
  16:  1f be         out  0x3f, r1  ; 63
  18:  cf e9         ldi  r28, 0x9F  ; 159
  1a:  cd bf         out  0x3d, r28  ; 61

0000001c <__do_copy_data>:
  1c:  10 e0         ldi  r17, 0x00  ; 0
  1e:  a0 e6         ldi  r26, 0x60  ; 96
  20:  b0 e0         ldi  r27, 0x00  ; 0
  22:  e8 e4         ldi  r30, 0x48  ; 72
  24:  f0 e0         ldi  r31, 0x00  ; 0
  26:  02 c0         rjmp  .+4        ; 0x2c <__do_copy_data+0x10>
  28:  05 90         lpm  r0, Z+
  2a:  0d 92         st  X+, r0
  2c:  a2 36         cpi  r26, 0x62  ; 98
  2e:  b1 07         cpc  r27, r17
  30:  d9 f7         brne  .-10       ; 0x28 <__do_copy_data+0xc>
  32:  02 d0         rcall  .+4        ; 0x38 <main>
  34:  07 c0         rjmp  .+14       ; 0x44 <_exit>

00000036 <__bad_interrupt>:
  36:  e4 cf         rjmp  .-56       ; 0x0 <__vectors>

00000038 <main>:

volatile uint8_t pinmask = 0x55;

int main(void)
{
  DDRB = 0xff;
  38:  8f ef         ldi  r24, 0xFF  ; 255
  3a:  87 bb         out  0x17, r24  ; 23
  
  while(1 != 0) PORTB = pinmask;
  3c:  80 91 60 00   lds  r24, 0x0060
  40:  88 bb         out  0x18, r24  ; 24
  42:  fc cf         rjmp  .-8        ; 0x3c <main+0x4>

00000044 <_exit>:
  44:  f8 94         cli

00000046 <__stop_program>:
  46:  ff cf         rjmp  .-2        ; 0x46 <__stop_program>

[Thomas E. (thomase)]

Dieter Frohnapfel schrieb:
> O.K., hier komplett ...

Bist du jetzt Ronny G., der unter anderem Namen postet? Oder was soll 
das?

mfg.

[Dieter F. (Gast)]

Thomas Eckmann schrieb:
> Bist du jetzt Ronny G., der unter anderem Namen postet? Oder was soll
> das?

Kannst Du mir das bitte erläutern? Was habe ich falsch gemacht? Habe 
lediglich das Code-Snippet in das Atmel-Studio 6.1 gepackt und 
compiliert. C-File = Angabe oben + #include <avr/io.h>, .lss-File wie 
gezeigt.

Kann eigentlich jeder andere auch machen - wollte nur helfen.

[Thomas E. (thomase)]

Dieter Frohnapfel schrieb:
> Kann eigentlich jeder andere auch machen - wollte nur helfen.

Deine Hilfsbereitschaft in allen Ehren, aber das hilft nicht weiter.

Das Programm, in beiden Versionen, kann gar nicht anders als 
funktionieren. Da bei ihm eine Version nicht funktioniert, ist bei ihm 
irgendwas faul. Das kann man aber nur an SEINEN Files erkennen.

mfg.

[Ronny G. (mogel)]

Bernd K. schrieb:
> Klingt als würde er die globale Variable nicht initialisieren. Das wäre
> ein compiler bug.

ich habe das Programm entsprechend angepasst -> keine Verbesserung

LSS und CPP habe ich in Anhang gepackt

[Dieter F. (Gast)]

Thomas Eckmann schrieb:
> Das Programm, in beiden Versionen, kann gar nicht anders als
> funktionieren.

Na, dann hättest Du vielleicht mal den Vergleichs-Post anschauen sollen

while(1 != 0) PORTB = pinmask;
  3c:  80 91 60 00   lds  r24, 0x0060


versus


//while(1 != 0) PORTB = pinmask;
  while(1 != 0) PORTB = 0x55;
  3c:  85 e5         ldi  r24, 0x55  ; 85


Das kann man sogar bei MEINEN File-Auszügen erkennen - wenn man den 
hinschaut.

[Bernd K. (prof7bit)]

00000038 <main>:

volatile uint8_t pinmask = 0x55;

int main(void)
{
  pinmask = 0x55;
  38:  85 e5         ldi  r24, 0x55  ; 85
  3a:  80 93 60 00   sts  0x0060, r24
  DDRB = 0xff;
  3e:  8f ef         ldi  r24, 0xFF  ; 255
  40:  87 bb         out  0x17, r24  ; 23
  
  while(1 != 0) PORTB = pinmask;
  42:  80 91 60 00   lds  r24, 0x0060
  46:  88 bb         out  0x18, r24  ; 24
  48:  fc cf         rjmp  .-8        ; 0x42 <__SREG__+0x3>

Das muss funktionieren. Ich sehe keinen Fehler.

[Thomas E. (thomase)]

Dieter Frohnapfel schrieb:
> Das kann man sogar bei MEINEN File-Auszügen erkennen - wenn man den
> hinschaut.
An deinen Auszügen sieht man, dass es funktioniert. Das sieht man an dem 
Quelltext aber auch so.

mfg.

[Thomas E. (thomase)]

Bernd K. schrieb:
> Das muss funktionieren. Ich sehe keinen Fehler.
Volle Zustimmung. Es sei denn das RAM ist kaputt.

mfg.

[Bernd K. (prof7bit)]

@Ronny

...und weiter oben bei __do_copy_data wird ebenfalls der Speicher bei 
0060 initialisiert. Und ich wette daß Dein hex file in der vorletzten 
Zeile eine 55 beinhaltet, vier Ziffern vor dem Zeilenende.

[Karl H. (kbuchegg)]

Dieter Frohnapfel schrieb:
> O.K., hier komplett ...

So blöd es auch klingt.
Aber jetzt muss auch noch das Hex-File her


Denn hier

  1c:  10 e0         ldi  r17, 0x00  ; 0
  1e:  a0 e6         ldi  r26, 0x60  ; 96
  20:  b0 e0         ldi  r27, 0x00  ; 0
  22:  ee e4         ldi  r30, 0x4E  ; 78
  24:  f0 e0         ldi  r31, 0x00  ; 0
  26:  02 c0         rjmp  .+4        ; 0x2c <__do_copy_data+0x10>
  28:  05 90         lpm  r0, Z+
  2a:  0d 92         st  X+, r0
  2c:  a2 36         cpi  r26, 0x62  ; 98
  2e:  b1 07         cpc  r27, r17
  30:  d9 f7         brne  .-10       ; 0x28 <__do_copy_data+0xc>

wird aus dem Flash die Intialisierung in den Speicher bugsiert.
Hier werden Bytes vom Flash 0x004E ins SRAM 0x0060 kopiert, von wo sich 
dann ...

  while(1 != 0) PORTB = pinmask;
  42:  80 91 60 00   lds  r24, 0x0060
  46:  88 bb         out  0x18, r24  ; 24

... das Programm den Wert holt.

D.h. die Frage lautet; wieso steht im Flash an der Adresse 0x004E nicht 
die 0x55, die dort eigentlich stehen sollten.

Leider sieht man das aber im LSS File nicht. Das hört ...

0000004c <__stop_program>:
  4c:  ff cf         rjmp  .-2        ; 0x4c <__stop_program>

... korrekterweise bei 0x4c/0x4d auf. Gleich dahinter müsste allerdings 
noch ein Byte mit dem Wert 0x55 stehen.

im Hex-File müsste man allerdings sehen, ob es da ist.

[Bernd K. (prof7bit)]

Dieter Frohnapfel schrieb im Beitrag #3873259:
> Bernd K. schrieb:
>> ...und weiter oben bei __do_copy_data wird ebenfalls der Speicher bei
>> 0060 initialisiert.
>
> Und womit? Ich würde gerne etwas hinzulernen. Ich sehe da kein 0x55 ...
> bin aber auch kein Assembler-Kenner ...
>
>
> 0000001c <__do_copy_data>:
>   1c:  10 e0         ldi  r17, 0x00  ; 0

Hier soll es hinkopiert werden, das ist der Startwert für das X Register 
(X = r26,r27)
>   1e:  a0 e6         ldi  r26, 0x60  ; 96
>   20:  b0 e0         ldi  r27, 0x00  ; 0

Und hier soll es herkommen, das ist der Startwert für das Z-Register 
(r30,r31)
>   22:  ee e4         ldi  r30, 0x4E  ; 78
>   24:  f0 e0         ldi  r31, 0x00  ; 0

>   26:  02 c0         rjmp  .+4        ; 0x2c <__do_copy_data+0x10>

inhalt von Programmspeicheradresse Z nach RAM-Speicheradresse X und 
beide eins erhöhen
>   28:  05 90         lpm  r0, Z+
>   2a:  0d 92         st  X+, r0

loop again until (X == 0062)
>   2c:  a2 36         cpi  r26, 0x62  ; 98
>   2e:  b1 07         cpc  r27, r17
>   30:  d9 f7         brne  .-10       ; 0x28 <__do_copy_data+0xc>

done with loop, now jump to main
>   32:  02 d0         rcall  .+4        ; 0x38 <main>
>   34:  0a c0         rjmp  .+20       ; 0x4a <_exit>

[Ronny G. (mogel)]

im HEX-File steht die 55 auch da.

Ich habe aber das Problem gefunden. Die ISP Frequenz war zu niedrig, so 
das ein Timeout kam. Eigentlich bei jeder Variante. Nur lief eben die 
Variante mit der Konstante, wärend die Variablen-Variante nicht lief. 
Daher habe ich den Fehler beim Flashen erstmal ignoriert.

danke für eure Hilfe

[Marc V. (Firma: Vescomp) (logarithmus)]

Ronny G. schrieb:
> ich habe das Programm entsprechend angepasst -> keine Verbesserung

 Keine Chance.
 Das, was du gepostet hast, funktioniert.
 PortB hat keine bits 6-7, bit 5 ist Reset, also:
 PB.0, PB.2, PB.4 gehen auf Log.1
 PB.1, PB.3 gehen auf Log.0

[Ingo (Gast)]

Erstens kommt es anders und zweitens als man denkt

[Thomas E. (thomase)]

Was lernen wir daraus?
Dass das Problem sich wieder einmal vor dem PC befand.

Kopf >>- Tisch, 3 Mal!

Marc Vesely schrieb:
> Ronny G. schrieb:
>> ich habe das Programm entsprechend angepasst -> keine Verbesserung
>
>  Keine Chance.
>  Das, was du gepostet hast, funktioniert.
>  PortB hat keine bits 6-7, bit 5 ist Reset, also:
>  PB.0, PB.2, PB.4 gehen auf Log.1
>  PB.1, PB.3 gehen auf Log.0

Du warst zu langsam.

mfg.

[Karl H. (kbuchegg)]

Ronny G. schrieb:
> im HEX-File steht die 55 auch da.
>
> Ich habe aber das Problem gefunden. Die ISP Frequenz war zu niedrig, so
> das ein Timeout kam. Eigentlich bei jeder Variante. Nur lief eben die
> Variante mit der Konstante, wärend die Variablen-Variante nicht lief.
> Daher habe ich den Fehler beim Flashen erstmal ignoriert.

Facepalm

[Dieter F. (Gast)]

Karl Heinz schrieb:
> Hier werden Bytes vom Flash 0x004E ins SRAM 0x0060 kopiert, von wo sich
> dann ...

Bernd K. schrieb:
> Und hier soll es herkommen, das ist der Startwert für das Z-Register
> (r30,r31)

O.K., ich habe meinen Post gelöscht, nachdem ich den Beitrag von 
Karl-Heinz gelesen habe ... sorry, aber da hatte ich zumindest 
verstanden (hoffentlich), das der Wert 0x55 aus dem Flash ins SRAM 
kopiert werden sollte.

Wenn ich das dann korrekt interpretiere, sollte im Hex-File an Stelle 
0x004E (Flash) eine 0x55 stehen - tut es aber nicht. Dort steht eine 
0x50, wenn ich das richtig sehe:

:1000000009C019C018C017C016C015C014C013C04D
:1000100012C011C011241FBECFE9CDBF10E0A0E671
:10002000B0E0E8E4F0E002C005900D92A236B1071E
:10003000D9F702D007C0E4CF8FEF87BB8091600073
:0800400088BBFCCFF894FFCF50
:02004800550061
:00000001FF

[Marc V. (Firma: Vescomp) (logarithmus)]

Ronny G. schrieb:
> Ich habe aber das Problem gefunden. Die ISP Frequenz war zu niedrig, so
> das ein Timeout kam. Eigentlich bei jeder Variante. Nur lief eben die

 Wie, zu niedrig ?

[Karl H. (kbuchegg)]

Dieter Frohnapfel schrieb:

> Wenn ich das dann korrekt interpretiere, sollte im Hex-File an Stelle
> 0x004E (Flash) eine 0x55 stehen

In deinem Programm hast du eine andere Adresslage. Warum auch immer.

> - tut es aber nicht. Dort steht eine
> 0x50, wenn ich das richtig sehe:

Du siehst das falsch. DIe 0x50 ist die Checksumme

[Karl H. (kbuchegg)]

Hier

:02004800550061
         ^
         |

sind die 0x55

[Dieter F. (Gast)]

Karl Heinz schrieb:
> 4c:  ff cf         rjmp  .-2        ; 0x4c <__stop_program>

> ... korrekterweise bei 0x4c/0x4d auf. Gleich dahinter müsste allerdings
> noch ein Byte mit dem Wert 0x55 stehen.

Da hätte ich jetzt erwartet, das nach ff cf -> 55 kommt. Vielleicht ist 
es aber auch schon zu spät und ich sollte mich lieber in die Ecke 
stellen und schämen ... :-(

[Bernd K. (prof7bit)]

Dieter Frohnapfel schrieb:
> :02004800550061

Dieter Frohnapfel schrieb:
> Wenn ich das dann korrekt interpretiere, sollte im Hex-File an Stelle
> 0x004E (Flash) eine 0x55 stehen - tut es aber nicht. Dort steht eine
> 0x50, wenn ich das richtig sehe:
>
> :1000000009C019C018C017C016C015C014C013C04D
> :1000100012C011C011241FBECFE9CDBF10E0A0E671
> :10002000B0E0E8E4F0E002C005900D92A236B1071E
> :10003000D9F702D007C0E4CF8FEF87BB8091600073
> :0800400088BBFCCFF894FFCF50

hier:
> :02 0048 00 5500 61

> :00000001FF

das ist adresse 0048 und nicht 004e aber die 55 ist da, bist Du sicher 
daß das hex zum .lss passt? Evtl nochmal kompilieren nachdem Du die eine 
Zeile noch eingefügt hast?

[Marc V. (Firma: Vescomp) (logarithmus)]

Dieter Frohnapfel schrieb:
> Wenn ich das dann korrekt interpretiere, sollte im Hex-File an Stelle
> 0x004E (Flash) eine 0x55 stehen - tut es aber nicht. Dort steht eine
> 0x50, wenn ich das richtig sehe:

 Das ist mit Sicherheit nicht der Hex-File vom geposteten Programm.

[Karl H. (kbuchegg)]

Dieter Frohnapfel schrieb:
> Karl Heinz schrieb:
>> 4c:  ff cf         rjmp  .-2        ; 0x4c <__stop_program>
>
>> ... korrekterweise bei 0x4c/0x4d auf. Gleich dahinter müsste allerdings
>> noch ein Byte mit dem Wert 0x55 stehen.
>
> Da hätte ich jetzt erwartet, das nach ff cf -> 55 kommt.

Tuts ja auch :-)

Nur im Hex-File ist das dann eben der nächste Record.

[Karl H. (kbuchegg)]

Bernd K. schrieb:

> das ist adresse 0048 und nicht 004e aber die 55 ist da, bist Du sicher
> daß das hex zum .lss passt? Evtl nochmal kompilieren nachdem Du die eine
> Zeile noch eingefügt hast?

Marc schrieb
> Das ist mit Sicherheit nicht der Hex-File vom geposteten Programm.


@Dieter
Du siehst hoffentlich, was du angerichtet hast.
Dein hilfreicher Versuch in allen Ehren. Aber jetzt kommt Verwirrung 
rein.


An alle:
Alles in Ordnung. Dieter hat seine Version des Programms benutzt,
Beitrag "Re: ATtiny13 und Konstanten vs. Variablen."
in der die Init Sequenz

  1c:  10 e0         ldi  r17, 0x00  ; 0
  1e:  a0 e6         ldi  r26, 0x60  ; 96
  20:  b0 e0         ldi  r27, 0x00  ; 0
  22:  e8 e4         ldi  r30, 0x48  ; 72
  24:  f0 e0         ldi  r31, 0x00  ; 0

so aussieht. Kopieren von 0x0048 nach 0x0060

Alles: Alles in Ordnung. Anderes Programm - andere Adresslage.

[Dieter F. (Gast)]

Karl Heinz schrieb:
> Nur im Hex-File ist das dann eben der nächste Record

O.K. dann muss ich mich dazu wohl mal schlau machen.

Bernd K. schrieb:
> bist Du sicher
> daß das hex zum .lss passt?

Zu meiner .lss - ja


Aber vielen Dank an alle - bin wieder etwas wissbegieriger geworden 
(schlauer kommt hoffentlich noch :-) )

[Ronny G. (mogel)]

Marc Vesely schrieb:
> Wie, zu niedrig ?

ich bin mit dem STK600 gerade am Testen bzw. Einarbeiten. Mit dem 
mega2560 funktionierte es alles (mehr oder weniger) auf Anhieb. Dann 
habe ich auf der Kleinen gewechselt und nichts ging mehr. Mit viel 
Suchen und Einstellungen und Tests habe ich das dann irgendwie halbwegs 
zum Laufen bekommen. Dabei habe ich aber auch die ISP Geschwindigkeit 
auf 5kHz gesetzt.

[Bernd K. (prof7bit)]

Man kann übrigens das hex file auch mit avr-objdump parsen und 
disassemblieren lassen, dann sieht man auch die 55 am Ende:

$ avr-objdump -j .sec1 -d -m avr5 test.hex 

test.hex:     Dateiformat ihex


Disassembly of section .sec1:

00000000 <.sec1>:
   0:   09 c0           rjmp    .+18            ;  0x14
   2:   19 c0           rjmp    .+50            ;  0x36
   4:   18 c0           rjmp    .+48            ;  0x36
   6:   17 c0           rjmp    .+46            ;  0x36
   8:   16 c0           rjmp    .+44            ;  0x36
   a:   15 c0           rjmp    .+42            ;  0x36
   c:   14 c0           rjmp    .+40            ;  0x36
   e:   13 c0           rjmp    .+38            ;  0x36
  10:   12 c0           rjmp    .+36            ;  0x36
  12:   11 c0           rjmp    .+34            ;  0x36
  14:   11 24           eor     r1, r1
  16:   1f be           out     0x3f, r1        ; 63
  18:   cf e9           ldi     r28, 0x9F       ; 159
  1a:   cd bf           out     0x3d, r28       ; 61
  1c:   10 e0           ldi     r17, 0x00       ; 0
  1e:   a0 e6           ldi     r26, 0x60       ; 96
  20:   b0 e0           ldi     r27, 0x00       ; 0
  22:   e8 e4           ldi     r30, 0x48       ; 72
  24:   f0 e0           ldi     r31, 0x00       ; 0
  26:   02 c0           rjmp    .+4             ;  0x2c
  28:   05 90           lpm     r0, Z+
  2a:   0d 92           st      X+, r0
  2c:   a2 36           cpi     r26, 0x62       ; 98
  2e:   b1 07           cpc     r27, r17
  30:   d9 f7           brne    .-10            ;  0x28
  32:   02 d0           rcall   .+4             ;  0x38
  34:   07 c0           rjmp    .+14            ;  0x44
  36:   e4 cf           rjmp    .-56            ;  0x0
  38:   8f ef           ldi     r24, 0xFF       ; 255
  3a:   87 bb           out     0x17, r24       ; 23
  3c:   80 91 60 00     lds     r24, 0x0060
  40:   88 bb           out     0x18, r24       ; 24
  42:   fc cf           rjmp    .-8             ;  0x3c
  44:   f8 94           cli
  46:   ff cf           rjmp    .-2             ;  0x46
  48:   55 00           .word   0x0055  ; ????

letzte Zeile:

48:   55 00           .word   0x0055  ; ????