AVR Atmega88PA Interrupts werden nich ausgeführt, sondern "soft"-Reset

[Laurens M. (fr34k1)]

Hallo,
meine AVR Atmega88PA Interrupts werden nich ausgeführt, sondern es wird 
ein "soft"-Reset ausgelöst.
Danach sind alle Bits im MCUSR 0.

Erwartet: LED geht an und bleibt an.
Was passiert: LED geht kurz an bis Timer bei "20"<<8 und danach blinkt 
danach langsam. Im Takt des Timers (Overflow)

Immer wenn ein Interupt ausgeführt werden sollte springt es zum Anfang. 
Die Interruptroutine wird nicht ausgeführt.
Wo könnte das Problem liegen?

Habe den Code für atmega88 und atmega88p compiliert. Immer das gleiche, 
auch auf anderer Hardware.

Bad Interrupt Routine wird auch nicht ausgeführt. Bei anderen Interupts 
passiert auch das gleiche.

Eclipse CDT mit AVR Plugin
avr-libc avrdude avr-gcc
gcc version 4.3.3 (GCC)
Ubuntu 9.10

Hier der Code:

#include <avr/io.h>
#include <avr/interrupt.h>
ISR(TIMER1_COMPA_vect)
{
  TCNT1H = 0;
  TCNT1L = 0;
  //  if (PORTD & (1 << PORTD7)) {
  //    PORTD &= ~(1 << PORTD7); ///LED off
  //  } else {
  //    PORTD |= (1 << PORTD7); ///LED on
  //  }
}
int main() {
  DDRD = (1 << PORTD7);

  if (PORTD & (1 << PORTD7)) { //if on
    PORTD &= ~(1 << PORTD7); ///LED off
  } else {
    PORTD |= (1 << PORTD7); ///LED on
  }

  OCR1AH = 20;
  OCR1AL = 0;
  TIMSK1 = (1 << OCIE1A);
  TCCR1B = (1 << CS12);
  //  TCNT1H = 0;
  //  TCNT1L = 0;
  sei();
  while (1) {
  }
  return 0;
}

Danke für eure Hilfe.

[Hc Z. (mizch)]

Ich kenne die Eclipse-Umgebung nicht.  Kann es sein, dass Du dort den 
falschen MCU-Typ eingestellt hast, so dass der falsche Interrupt-Vektor 
gesetzt wird oder dein ISR gar nicht als Interrupt-Routine erkannt wird?

Steht im Code auf Byte-Adresse 0x2c (Wort: 0x16) ein Sprung zu Deiner 
Interrupt-Routine?  (Ggfs. die ersten 3 Zeilen der .hex mitliefern.) 
Oder steht da derselbe Sprung wie direkt davor und danach?

[Laurens M. (fr34k1)]

Hazeh danke für die Antwort.
Haben das Problem gefunden. Lag bei den Standardeinstellungen vom 
AVR-Plugin für Eclipse.
Da beim Compilieren keine .hex Datei, sondern nur ein .elf Datei 
erstellt wurde, hatten wir den MC mit der .elf programmiert. Lief alles 
wunderbar abgesehen von den Interrupts.
Im Assembler Code war natürlich alles richtig...
Nach 25 Std. Suche...
Häkchen bei "Generate Hexfile for Flash memory" in Project -> Properties 
-> Build -> Settings -> Tool Settings -> Additional Tools in Toolchain 
setzten und es funktioniert. :)
Schönen Abend noch!

[Matthias (Gast)]

Hallo,

ich habe so ziemlich das gleiche Problem. Ein Interrupt fuehrt immer 
dazu, dass der Code von neuem ausgefuehrt wird.

Ich benutze avr-gcc 4.1.2 und schreibe die .hex Datei mit avrdude ins 
Flash. Als MC kommt im Moment ein atmega8 zum Einsatz. Zur 
Vollstaendigkeit, das Programm sieht folgendermassen aus:

#include <avr/io.h>
#include <avr/interrupt.h>
 
volatile uint8_t flag;

ISR( TIMER2_OVF_vect ) {
    flag = 1;
}

int main(void) {
 
    DDRD = 0xFF;
 
// Timer2 konfigurieren
    TCCR2 = (1 << CS22) | (1 << CS21);
    TIMSK |= (1 << TOIE2);

    sei();

    while(1) {
        if (flag == 1) {
            flag = 0;
            PORTD ^= (1 << PD0);    // LED toggeln
        }
    }
}

Nun wollte ich, wie <HC Zimmerer> vorschlug, im .hex file nachschauen, 
ob an der richtigen Stelle auch die Sprungadresse zu meiner ISR Funktion 
steht.

Die Sprungadresse fuer den Interrupt TIMER2_OVF muss an 0x004 im 
Programm Code stehen - dem Handbuch entnommen. Nun bin ich mir nicht 
sicher, wie ich das hex-file in kate lesen soll:

:1000000012C02CC02BC02AC029C028C027C026C0BF
:1000100025C024C023C022C021C020C01FC01EC0D4
:100020001DC01CC01BC011241FBECFE5D4E0DEBF25

Ich suche also das 5.Bit in der ersten Zeile was sagt "2B" also 43. Dann 
sollte meine Interrupt Funktion bei Bit 43 beginnen. Allerdings macht 
mich stutzig, dass die ersten 3 Zeilen bei allen meinen hex Files von 
verschiedenen Programmen immer gleich aussehen. Was mache ich falsch?

Danke schon mal fuer die Hilfe.

[Oliver (Gast)]

>Nun bin ich mir nicht
>sicher, wie ich das hex-file in kate lesen soll:

Dann schau doch in der .lss-datei nach. Da steht die Sprungtabelle im 
Klartext.

Bleibt die Frage, woran du erkennst, daß das Programm immer wieder von 
vorne losläuft.

Oliver

[Matthias (Gast)]

Das Programm wie oben abgedruckt bringt die LED nicht zum leuchten. 
Toggle ich aber den Ausgang mit der LED vor dem sei() und fuege auch 
noch ein delay vor dem sei() ein, dann blinkt die LED.

Daraus habe ich geschlossen, dass der Aufruf sei() den Interrupt 
TIMER2_OVF aktiviert und ausfuehren will, aber an die falsche Stelle 
springt naemlich an den Anfang vom Programm. Dadurch wird die LED wieder 
ausgeschaltet und alles geht wieder von vorne los. Vielleicht habe ich 
hier auch etwas uebersehen.

Leider weiss ich nicht, wonach ich in der main.lss suchen soll, daher 
einfach die ganze Datei:

main.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         000000a0  00000000  00000000  00000074  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .bss          00000001  00800060  00800060  00000114  2**0
                  ALLOC
  2 .stab         00000378  00000000  00000000  00000114  2**2
                  CONTENTS, READONLY, DEBUGGING
  3 .stabstr      00000054  00000000  00000000  0000048c  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_aranges 00000014  00000000  00000000  000004e0  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_pubnames 0000001b  00000000  00000000  000004f4  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_info   0000009c  00000000  00000000  0000050f  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_abbrev 00000077  00000000  00000000  000005ab  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_line   000000e6  00000000  00000000  00000622  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_frame  00000028  00000000  00000000  00000708  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_str    000000b1  00000000  00000000  00000730  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  12 c0         rjmp  .+36       ; 0x26 <__ctors_end>
   2:  2c c0         rjmp  .+88       ; 0x5c <__bad_interrupt>
   4:  2b c0         rjmp  .+86       ; 0x5c <__bad_interrupt>
   6:  2a c0         rjmp  .+84       ; 0x5c <__bad_interrupt>
   8:  29 c0         rjmp  .+82       ; 0x5c <__bad_interrupt>
   a:  28 c0         rjmp  .+80       ; 0x5c <__bad_interrupt>
   c:  27 c0         rjmp  .+78       ; 0x5c <__bad_interrupt>
   e:  26 c0         rjmp  .+76       ; 0x5c <__bad_interrupt>
  10:  25 c0         rjmp  .+74       ; 0x5c <__bad_interrupt>
  12:  24 c0         rjmp  .+72       ; 0x5c <__bad_interrupt>
  14:  23 c0         rjmp  .+70       ; 0x5c <__bad_interrupt>
  16:  22 c0         rjmp  .+68       ; 0x5c <__bad_interrupt>
  18:  21 c0         rjmp  .+66       ; 0x5c <__bad_interrupt>
  1a:  20 c0         rjmp  .+64       ; 0x5c <__bad_interrupt>
  1c:  1f c0         rjmp  .+62       ; 0x5c <__bad_interrupt>
  1e:  1e c0         rjmp  .+60       ; 0x5c <__bad_interrupt>
  20:  1d c0         rjmp  .+58       ; 0x5c <__bad_interrupt>
  22:  1c c0         rjmp  .+56       ; 0x5c <__bad_interrupt>
  24:  1b c0         rjmp  .+54       ; 0x5c <__bad_interrupt>

00000026 <__ctors_end>:
  26:  11 24         eor  r1, r1
  28:  1f be         out  0x3f, r1  ; 63
  2a:  cf e5         ldi  r28, 0x5F  ; 95
  2c:  d4 e0         ldi  r29, 0x04  ; 4
  2e:  de bf         out  0x3e, r29  ; 62
  30:  cd bf         out  0x3d, r28  ; 61

00000032 <__do_copy_data>:
  32:  10 e0         ldi  r17, 0x00  ; 0
  34:  a0 e6         ldi  r26, 0x60  ; 96
  36:  b0 e0         ldi  r27, 0x00  ; 0
  38:  e0 ea         ldi  r30, 0xA0  ; 160
  3a:  f0 e0         ldi  r31, 0x00  ; 0
  3c:  02 c0         rjmp  .+4        ; 0x42 <.do_copy_data_start>

0000003e <.do_copy_data_loop>:
  3e:  05 90         lpm  r0, Z+
  40:  0d 92         st  X+, r0

00000042 <.do_copy_data_start>:
  42:  a0 36         cpi  r26, 0x60  ; 96
  44:  b1 07         cpc  r27, r17
  46:  d9 f7         brne  .-10       ; 0x3e <.do_copy_data_loop>

00000048 <__do_clear_bss>:
  48:  10 e0         ldi  r17, 0x00  ; 0
  4a:  a0 e6         ldi  r26, 0x60  ; 96
  4c:  b0 e0         ldi  r27, 0x00  ; 0
  4e:  01 c0         rjmp  .+2        ; 0x52 <.do_clear_bss_start>

00000050 <.do_clear_bss_loop>:
  50:  1d 92         st  X+, r1

00000052 <.do_clear_bss_start>:
  52:  a1 36         cpi  r26, 0x61  ; 97
  54:  b1 07         cpc  r27, r17
  56:  e1 f7         brne  .-8        ; 0x50 <.do_clear_bss_loop>
  58:  11 d0         rcall  .+34       ; 0x7c <main>
  5a:  21 c0         rjmp  .+66       ; 0x9e <_exit>

0000005c <__bad_interrupt>:
  5c:  d1 cf         rjmp  .-94       ; 0x0 <__vectors>

0000005e <__vector_4>:
volatile uint8_t flag;

 
// Timer2 overflow Interrupt
// hier wird der Hauptschleife ein neuer Timerinterrupt signalisiert
ISR( TIMER2_OVF_vect ) {
  5e:  1f 92         push  r1
  60:  0f 92         push  r0
  62:  0f b6         in  r0, 0x3f  ; 63
  64:  0f 92         push  r0
  66:  11 24         eor  r1, r1
  68:  8f 93         push  r24
    flag = 1;
  6a:  81 e0         ldi  r24, 0x01  ; 1
  6c:  80 93 60 00   sts  0x0060, r24
  70:  8f 91         pop  r24
  72:  0f 90         pop  r0
  74:  0f be         out  0x3f, r0  ; 63
  76:  0f 90         pop  r0
  78:  1f 90         pop  r1
  7a:  18 95         reti

0000007c <main>:
}

int main(void) {
 
// IO konfigurieren
    DDRD = 0xFF;
  7c:  8f ef         ldi  r24, 0xFF  ; 255
  7e:  81 bb         out  0x11, r24  ; 17
 
// Timer2 konfigurieren
    TCCR2 = (1 << CS22) | (1 << CS21);
  80:  86 e0         ldi  r24, 0x06  ; 6
  82:  85 bd         out  0x25, r24  ; 37
    TIMSK = (1 << TOIE2);
  84:  80 e4         ldi  r24, 0x40  ; 64
  86:  89 bf         out  0x39, r24  ; 57

// Interrupts freigeben
    sei();
  88:  78 94         sei

// Endlose Hauptschleife
    while(1) {
        if (flag == 1) { // Neuer Timerzyklus ?
  8a:  90 91 60 00   lds  r25, 0x0060
  8e:  91 30         cpi  r25, 0x01  ; 1
  90:  e1 f7         brne  .-8        ; 0x8a <main+0xe>
            flag = 0;
  92:  10 92 60 00   sts  0x0060, r1
 
            PORTD ^= (1 << PD0);    // LED toggeln
  96:  82 b3         in  r24, 0x12  ; 18
  98:  89 27         eor  r24, r25
  9a:  82 bb         out  0x12, r24  ; 18
  9c:  f6 cf         rjmp  .-20       ; 0x8a <main+0xe>

0000009e <_exit>:
  9e:  ff cf         rjmp  .-2        ; 0x9e <_exit>

Ich sehe, dass an den Speicheradressen 5e-7b wohl der Code fuer meinen 
ISR steht, sehe allerdings nicht, wo der Sprung dahin definiert wird.

Danke fuer die Hilfe.

[Stefan E. (sternst)]

Du hast irgendeinen elementaren Fehler gemacht. Vielleicht 
Controller-Typ beim Linken nicht mit angegeben? Poste doch mal den 
kompletten Build-Output.

[Matthias (Gast)]

Der build output sieht so aus:

-------- begin --------
avr-gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux)
Copyright (C) 2006 Free Software Foundation, Inc.     
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiling C: main.c
avr-gcc -c -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=1000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall 
-Wstrict-prototypes -Wundef -Wa,-adhlns=obj/main.lst  -std=gnu99 --combine 
-fwhole-program -Wundef -MD -MP -MF .dep/main.o.d main.c -o 
obj/main.o                                                                               

Linking: main.elf
avr-gcc -mmcu=atmega8 -I. -gdwarf-2 -DF_CPU=1000000UL -Os -funsigned-char 
-funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes 
-Wundef -Wa,-adhlns=obj/main.o  -std=gnu99 --combine -fwhole-program 
-Wundef -MD -MP -MF .dep/main.elf.d obj/main.o --output main.elf 
-Wl,-Map=main.map,--cref    -lm                                          

Creating load file for Flash: main.hex
avr-objcopy -O ihex -R .eeprom main.elf main.hex

Creating load file for EEPROM: main.eep
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" \
--change-section-lma .eeprom=0 -O ihex main.elf main.eep
avr-objcopy: --change-section-lma .eeprom=0x0000000000000000 never used

Creating Extended Listing: main.lss
avr-objdump -h -S main.elf > main.lss

Creating Symbol Table: main.sym
avr-nm -n main.elf > main.sym

Size after:
main.elf  :
section           size      addr
.text              160         0
.bss                 1   8388704
.stab              888         0
.stabstr            84         0
.debug_aranges      20         0
.debug_pubnames     27         0
.debug_info        156         0
.debug_abbrev      119         0
.debug_line        230         0
.debug_frame        40         0
.debug_str         177         0
Total             1902



-------- end --------

[Tim (Gast)]

Prüfe mal bitte ob TIMER2_OVF_vect in den .h auch wirklich definiert
ist. Hatte hier auch schon das Problem, daß der GCC zwar die ISR
einbaut, aber nicht in der IRQ Vector Tabelle eingebunden hat.
Grund war ein Falsch geschriebener ISR Name....

Eine Fehlermeldung gab es komischerweise nicht.

[Stefan E. (sternst)]

Tim schrieb:
> Prüfe mal bitte ob TIMER2_OVF_vect in den .h auch wirklich definiert
> ist. Hatte hier auch schon das Problem, daß der GCC zwar die ISR
> einbaut, aber nicht in der IRQ Vector Tabelle eingebunden hat.
> Grund war ein Falsch geschriebener ISR Name....

Unnötig. Die Funktion ist ja als Interrupt-Funktion übersetzt worden 
(und auch mit der richtigen Vektor-Nummer), also kann es das nicht sein.

@ Matthias:
Ich kann im Build-Output nichts entdecken. Ich würde es mal mit einer 
etwas aktuelleren Toolchain probieren.

[Grrrr (Gast)]

Stefan Ernst schrieb:
> Unnötig. Die Funktion ist ja als Interrupt-Funktion übersetzt worden
> (und auch mit der richtigen Vektor-Nummer), also kann es das nicht sein.

Wo siehst Du hier "die richtige Vektor-Nummer"?

[Hc Z. (mizch)]

> avr-gcc -mmcu=atmega8 [...]

In der Überschrift steht aber ATmega88 (nicht ATmega8).

[Stefan E. (sternst)]

Grrrr schrieb:
> Stefan Ernst schrieb:
>> Unnötig. Die Funktion ist ja als Interrupt-Funktion übersetzt worden
>> (und auch mit der richtigen Vektor-Nummer), also kann es das nicht sein.
>
> Wo siehst Du hier "die richtige Vektor-Nummer"?

0000005e <__vector_4>:

[Tim (Gast)]

@Stefan Ernst:
Wie gesagt, gleiches Problem hatte ich hier auch schon.
Ursache war der Umstieg auf einen grösseren AVR (16 auf 64 oder so).

Und damit war ich wohl zu spät :-)
Vielleicht solltest du auch noch -mmcu= an deine Hardware anpassen.

[Stefan E. (sternst)]

Hc Zimmerer schrieb:
>> avr-gcc -mmcu=atmega8 [...]
>
> In der Überschrift steht aber ATmega88 (nicht ATmega8).

Was daran liegt, dass der Frager einen alten Thread gekapert hat.

[Hc Z. (mizch)]

> Was daran liegt, dass der Frager einen alten Thread gekapert hat.

Argl.

[Peter D. (peda)]

Hc Zimmerer schrieb:
>> avr-gcc -mmcu=atmega8 [...]
>
> In der Überschrift steht aber ATmega88 (nicht ATmega8).

Ja, das verwirrt ungemein.

Deshalb @Matthias (Gast)

Schreib 100-mal an die Tafel:
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"
"Ich soll nicht fremde Threads hijacken!"


Peter

[Matthias (Gast)]

Hallo,

ja, ich habe einen alten thread missbraucht. Meiner Ansicht nach leide 
ich an einem sehr aehnlichen Problem, wie der anfaengliche Poster. Aber 
das war wohl eine schlechte Idee.

Zurueck zu meinem Problem. In der iom8.h steht:

...
/* Timer/Counter2 Overflow */
#define TIMER2_OVF_vect      _VECTOR(4)
#define SIG_OVERFLOW2      _VECTOR(4)
...

Ich hoffe, dass beantwortet die Frage von Tim.

Die toolchain umfasst wohl den avr-gcc compiler und avrdude? Ich habe da 
einfach ein Paket meiner Distribution installiert und mir dazu keine 
Gedanken gemacht. Es gibt bei openSUSE ein Packet cross-avr-gcc und ein 
Paket cross-avr-gcc44 welche jeweils die Compiler und Support Files 
beinhalten. Vielleicht haette ich da die Version cross-avr-gcc44 nehmen 
sollen?


Es scheint mir aber so, als ob meine Interpretation der Dinge richtig 
liegt und meine ISR Prozedur nicht angesprungen wird. Es ist also ein 
Problem bei der Compilierung, oder?

[Stefan E. (sternst)]

Matthias schrieb:
> Es scheint mir aber so, als ob meine Interpretation der Dinge richtig
> liegt und meine ISR Prozedur nicht angesprungen wird. Es ist also ein
> Problem bei der Compilierung, oder?

Genauer gesagt ein Problem beim Linken, der Vektor wird nicht 
eingetragen. Die fertigen avr-gcc-Pakete der Distributionen sind 
ziemlich bekannt dafür, häufiger mal buggy zu sein.

Schau mal bei AVR-Freaks vorbei. Dort gibt es ein Skript, mit dem man 
sich avr-gcc ziemlich einfach selbst übersetzen kann. Seit Kurzem gibt 
es dort auch fertige Deb-Pakete, es gibt dazu einen Thread mit der 
Adresse.

[Laurens M. (fr34k1)]

Deine .lss-Datei muss nachher folgendes enthalten:

...
00000000 <__vectors>:
   0:  12 c0         rjmp  .+36       ; 0x26 <__ctors_end>
   2:  2c c0         rjmp  .+88       ; 0x5c <__bad_interrupt>
   4:  2b c0         rjmp  .+86       ; 0x5c <__bad_interrupt>
   6:  2a c0         rjmp  .+84       ; 0x5c <__bad_interrupt>
   8:  2a c0         rjmp  .+84       ; 0x5e <__vector_4>
   a:  28 c0         rjmp  .+80       ; 0x5c <__bad_interrupt>
...

[Christian H. (netzwanze)]

"bad interrupt" setzt man am besten auf eine Routine, welche eine LED 
einschaltet und dann in einer Endlosschleife hängen bleibt - falls man 
noch einen Pin frei hat. Geht alles gut, sollte die LED niemals 
leuchten. Wenn doch, trat ein nicht abgefangener Interrupt auf.

[Oliver (Gast)]

Stefan Ernst schrieb:
> Der build output sieht so aus:
>
>
> -------- begin --------
>
> avr-gcc (GCC) 4.1.2 20070115 (prerelease) (SUSE Linux)
> Copyright (C) 2006 Free Software Foundation, Inc.


Also, dein Programm ist in Ordnung, der Vektor wird aber nicht in die 
Sprungtabelle eingetragen.

Wie schon gesagt wurde, besorge dir erst einmal eine aktuelle und 
nachgewiesenermassen funktionsfähige avr-gcc-Version. 3 Jahre alte 
"prereleases" sind da eher nicht vertrauenswürdig.

Oliver

[Stefan E. (sternst)]

Oliver schrieb:
> Stefan Ernst schrieb:
>> Der build output sieht so aus:

Hä???

[Oliver (Gast)]

Stefan Ernst schrieb:
> Oliver schrieb:
>> Stefan Ernst schrieb:
>>> Der build output sieht so aus:
>
> Hä???

Hmpf.
Da habe ich den Zitat-Link des falschen Beitrags erwischt. Sollte 
natürlich so lauten:

Matthias schrieb:
> Der build output sieht so aus:

Ist aber schon lustig, daß man über den Zitate-Link aus anderen 
Beiträgen die Autoren beliebig zuordnen kann.

Oliver

[Иван S. (ivan)]

Peter Dannegger schrieb:
>> In der Überschrift steht aber ATmega88 (nicht ATmega8).
>
> Ja, das verwirrt ungemein.

Was spricht dagegen, das Subjekt zu ändern?

Iwan