While(1) wird nach setzen des Timer-Interrupts nicht mehr aufgerufen

[Florian C. (flo94)]

Hallo an alle!

Ich besitze ein ATmega64A Board (Takt auf internen 8MHz RC-Oszillator 
gestellt), an dem ich ein paar Bus-Systeme auspobieren möchte. Gestern 
habe ich es das erste Mal in Betrieb genommen und jetzt ist ein äußerst 
merkwürdiger Fehler aufgetreten, vlt. findet ja eine von euch den 
Fehler...

Ich habe folgenden code programmiert, der einen Timer-Interrupt auslöst 
(sicherheitshalber sind nicht verwendete Bits auf 0 gestetzt) und 
zugleich blinkt eine LED im 1s-Takt in der While(1)-Schleife:

#define F_CPU 8000000UL        // define system clock with  8MHz

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>


int main(void)
{  
  TCNT0 = 0;
  TCCR0 &= (~(1<<COM00)) & (~(1<<COM01));  // normal operation mode, OC0 not connected to a pin
  TCCR0 |= (1<<WGM01);          // clear on compare matching
  TCCR0 &= (~(1<<WGM00));          // with OCR0
  TCCR0 |= (1<<CS00);            // set prescaler
  TCCR0 &= (~(1<<CS01)) & (~(1<<CS02));  // to 1 -> 12MHz
  
  OCR0 = 200;                // set compare value for timer0 to 200 (25µs)

  TIMSK |= (1<<OCIE0);          // enable interrupt for timer0
  
  DDRA |= (1<<PA0);
  DDRD |= (1<<PD1);

  sei();
  
  while(1)
  {
    PORTA ^= (1<<PA0);
    _delay_ms(500);
  }

  return 0;
}


ISR(TIMER0_COMP_vect)
{
  PORTD ^= (1<<PD1);
}

Mit diesem Code bekomme ich am Pin PD1 mit dem Oszi wie erwartet ein 
20kHz Rechteck-Signal. Jedoch blinkt die LED am Pin PA0 nicht mehr, 
sondern leuchtet dauerhaft!
Deaktiviere ich den Timer durch Auskommentieren der Zeile "CCR0 |= 
(1<<CS00);" toggelt der Pin PD1 logischerweise nichtmehr, aber dafür 
blinkt die LED an Port PA0.
Beides gleichzeitig scheint nicht zu funktionieren, bzw. befindet sich 
das Programm wsl. dauerhaft im ISR...

Was kann dieses eigenartige Verhalten auslösen oder worin liegt der 
Fehler?
Habe bereits Timer2 ausprobiert -> gleiches Ergebnis
Neues Projekt erstellt -> gleiches Ergebnis


Ich hoffe jemand kann mir helfen.

Danke und lG
Florian

[Carl D. (jcw2)]

.lss Datei erzeugt/angeschaut?
Darin steht, was wirklich passiert. Leider in Assembler, aber das lesen 
zu können und zu verstehen, ist nie verkehrt. Schreiben muß man's ja 
nicht unbedingt selber ;-)

[Christoph (gizmo)]

Der Atmega läuft mit 8MHz, deine ISR wird alle 1us, also mit 1MHz Takt 
aufgerufen.

Das lässt dem Atmega nur 8 Takte Zeit um in die ISR zu springen, die 
Register auf dem Stack zu sichern, read-modify-write auf PORTD 
auszuführen, Register vom Stack zurückholen und wieder ins Hauptprogramm 
zu springen.

Der Atmega hängt einfach ununterbrochen im Interrupt weil er keine Zeit 
fürs Hauptprogramm mehr hat.

Schau dir mal an wie man mit Atmega Timern eine PWM ausgibt, das 
funktioniert komplett in Hardware und verbraucht keine CPU-Takte.

[Volker S. (vloki)]

Musst du den Timer Interrupt(Flag) nicht löschen?

Andererseits müsste natürlich die Frequenz viel höher als 20kHz sein,
falls das Programm immer wieder in den IR-Vector springen würde.

(Sorry, kenn mich mit AVR IR-Handling nicht aus)

[Florian C. (flo94)]

Vielen Dank für die schnellen Antworten!

@Carl Drexler:
Die Datei wird erzeugt, aber auf den ersten Blick erkenne ich garnix, 
habe leider nur Grundahnung in Sachen ASM...

@ Christoph S:
Es war ein Fehler im Kommentar, es sind 25µs, habe es ausgebessert...

[S. Landolt (Gast)]

Arduino?

[Florian C. (flo94)]

@Volker SK:
Meines Wissens muss da nichts zurückgesetzt werden, ich habe ähnliche 
Codes (gleiche Syntax und Ablauf) bereits auf anderen Mikrocontrollern 
ohne Probleme implementieren können!
Stimmt, die Frequenz müsste deuitlich höher sein, wenn er dauerhaft im 
ISR hängt, also kann dies nicht der Fehler sein...

@S. Landolt:
Nein, ist dieses Board:
https://www.aliexpress.com/item/Atmega64-development-board-avr-development-board-learning-board-core-board-Free-Shipping/32705245588.html
Und als Entwicklungsumgebung verwende ich das AVR-Studio 7.0

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Florian C. schrieb:
> TCCR0 &= (~(1<<COM00)) & (~(1<<COM01));  // normal operation mode, OC0
> not connected to a pin
>   TCCR0 |= (1<<WGM01);          // clear on compare matching
>   TCCR0 &= (~(1<<WGM00));          // with OCR0
>   TCCR0 |= (1<<CS00);            // set prescaler
>   TCCR0 &= (~(1<<CS01)) & (~(1<<CS02));  // to 1 -> 12MHz

Und da blickst du noch durch? Was hältst du davon?:

TCCR0 = (1 << WGM01) | (1 << CS00);

[Kamest (Gast)]

> Der Atmega läuft mit 8MHz, deine ISR wird alle 1us, also mit 1MHz Takt
> aufgerufen.

Die Interruptroutine wir 40.000 mal pro Sekunde aufgerufen.

> Der Atmega hängt einfach ununterbrochen im Interrupt weil er keine Zeit
> fürs Hauptprogramm mehr hat.

Ununterbrochen nicht, da mindesten 1 Befehl nach dem RETI ausgeführt 
wird.
Das Hauptprogramm dürfte trotzdem nur sehr langsam ausgeführt werden 
(40.000 x Zeit in der IR ist verdammt lang).

Fazit: Das Programm ist ungeeignet für die zu lösende Aufgabe.

[Erwin D. (Gast)]

S. Landolt schrieb:
> Arduino?

Was ist damit?

[Florian C. (flo94)]

@Matthias S.
Ich finde es einfacher wenn ich es nach Bit-Typ unterteile, aber daran 
dürfte es nicht scheitern...

@Kamest:
Ich habe auch bereits den Prescaler auf 8 gesetzt -> gleiches Ergebnis

Das Programm dient nur zum Austesten des Timer-Interrupts, muss also 
keinen Sinn Ergeben, sondern dient lediglich zum Beheben des Fehlers...

[Volker S. (vloki)]

Kamest schrieb:
> Ununterbrochen nicht, da mindesten 1 Befehl nach dem RETI ausgeführt
> wird.
> Das Hauptprogramm dürfte trotzdem nur sehr langsam ausgeführt werden
> (40.000 x Zeit in der IR ist verdammt lang).

Ja stimmt, das _delay_ms(500) Macro wird wohl sehr viel läääääänger 
brauchen.

[Volker S. (vloki)]

Volker S. schrieb:
> Kamest schrieb:
>> Ununterbrochen nicht, da mindesten 1 Befehl nach dem RETI ausgeführt
>> wird.
>> Das Hauptprogramm dürfte trotzdem nur sehr langsam ausgeführt werden
>> (40.000 x Zeit in der IR ist verdammt lang).
>
> Ja stimmt, das _delay_ms(500) Macro wird wohl sehr viel läääääänger
> brauchen.


Florian C. schrieb:
> Das Programm dient nur zum Austesten des Timer-Interrupts, muss also
> keinen Sinn Ergeben, sondern dient lediglich zum Beheben des Fehlers...
Muss der wirklich in so kleinen Zeitabständen kommen?

[Florian C. (flo94)]

So, habe den Prescaler jetzt auf 8 gesetzt und die Delay auf 100ms:
2.5kHz Augabe an PD1 und LED an PA0 trotzdem dauerhaft an ...

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Florian C. schrieb:
> @Matthias S.
> Ich finde es einfacher wenn ich es nach Bit-Typ unterteile, aber daran
> dürfte es nicht scheitern...

Es geht hier nicht um den Bittyp, sondern darum, das du den Timer in 
Häppchen initialisierst, was manchmal zu lustigen Effekten führen kann. 
Ein atomarer Zugriff, der alle Bits so setzt, wie sie sein sollen, 
bewahrt einen davor.
Das ganze geht übrigens auch komplett ohne Interrupt und läuft im 
Hintergrund, wenn du 'Toggle On Compare Match' benutzt und PB4 (OC0) als 
Ausgang.

[Carl D. (jcw2)]

Christoph S. schrieb:
> Der Atmega läuft mit 8MHz, deine ISR wird alle 1us, also mit 1MHz Takt
> aufgerufen.
Das steht aber nur im Kommentar. Das Compare-Register wird auf 200 
gesetzt.

Hier mal eine überarbeitete Timer-Initialisierung:

  TCCR0 = 
          (0b00<<COM00)  // normal operation mode, OC0 not connected to pin
        | (0b10<<WGM00)  // clear on compare matching with OCR0
        | (0b001<<CS00); // set prescaler to /1  8MHz -> 125ns Tick

  OCR0 = 200;    // 200*125ns -> Interrupt alle 25μs

Bei 8MHz sollte das 25μs-Pinwackeln nicht zu 5-stelliger Verlängerung 
des delay() führen.

[Florian C. (flo94)]

Hatte dadurch bisher noch nie Probleme, kann es aber gerne auch ander 
versuchen.

Ich habe jetzt mal den zweiten Kanal des Oszis an den Ausgang der LED 
geklemmt:
Die LED toggelt mit der gleichen Frequenz wie der 
Timer-Interrupt-Ausgang, lediglich um 180° phasenverschoben! Wie kann 
das sein?

[Volker S. (vloki)]

Florian C. schrieb:
> Und als Entwicklungsumgebung verwende ich das AVR-Studio 7.0

Kannst du damit nicht debuggen?
Müsste man doch leicht erkennen könne , was da schief läuft.

[Florian C. (flo94)]

@Carl Drexler:
Habe deine Initialisierung probiert -> selbes Ergebnis

[Anständiger Definer (Gast)]

Kurzes OT

Matthias S. schrieb:
> Und da blickst du noch durch? Was hältst du davon?:TCCR0 = (1 << WGM01)
> | (1 << CS00);

Danke, jetzt bestätigen die avr Jünger selbst, dass die 1 << 
Schreibweise nicht zu lesen ist.
Und noch besser die Variante von CD (0b00<<COM00). ?

[S. Landolt (Gast)]

> Wie kann das sein?
Ständiger Neustart nach erstmaligem ISR-Aufruf? Aber warum?

[Carl D. (jcw2)]

Florian C. schrieb:
> @Carl Drexler:
> Habe deine Initialisierung probiert -> selbes Ergebnis

Ja hoffentlich. Ich hab ja die selben Werte übergeben, nur anders 
(durchschaubarer) formuliert. Nur die Kommentare waren im Original 
"leicht veraltet".

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Anständiger Definer schrieb:
> Danke, jetzt bestätigen die avr Jünger selbst, dass die 1 <<
> Schreibweise nicht zu lesen ist.
> Und noch besser die Variante von CD (0b00<<COM00). ?

Aha? Dann erklär doch bitte mal, was du meinst.
Die Schreibweise

TCCR0 = (1 << WGM01) | (1 << CS00);

setzt genau die Bits WGM01 und CS00 im TCCR0 Register. Alle anderen 
werden auf 0 gesetzt. Wenn du das nicht verstehst:
https://www.mikrocontroller.net/articles/Bitmanipulation

[Carl D. (jcw2)]

S. Landolt schrieb:
>> Wie kann das sein?
> Ständiger Neustart nach erstmaligem ISR-Aufruf? Aber warum?

Vielleicht weil die HW nicht die Interruptvektoren hat, die der Compiler 
vermutet. Deshalb .lss-File anschauen.

[(prx) A. K. (prx)]

Die M103C Fuse.

[Carl D. (jcw2)]

Matthias S. schrieb:
> Anständiger Definer schrieb:
>> Danke, jetzt bestätigen die avr Jünger selbst, dass die 1 <<
>> Schreibweise nicht zu lesen ist.
>> Und noch besser die Variante von CD (0b00<<COM00). ?
>
> Aha? Dann erklär doch bitte mal, was du meinst.
> Die Schreibweise
>

> TCCR0 = (1 << WGM01) | (1 << CS00);
>

> setzt genau die Bits WGM01 und CS00 im TCCR0 Register. Alle anderen
> werden auf 0 gesetzt. Wenn du das nicht verstehst:
> https://www.mikrocontroller.net/articles/Bitmanipulation

Er meint, daß ich die Bits zusammengeschrieben hab und dann auf das 
unterste Bit ausrichte. Damit sieht man direkt den Wert aus dem DB.

[Florian C. (flo94)]

Das steht im lss-File: (mein Programm heißt TI_Error)

TI_Error.elf:     file format elf32-avr

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .data         00000000  00800100  00800100  0000016c  2**0
                  CONTENTS, ALLOC, LOAD, DATA
  1 .text         00000118  00000000  00000000  00000054  2**1
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .comment      00000030  00000000  00000000  0000016c  2**0
                  CONTENTS, READONLY
  3 .note.gnu.avr.deviceinfo 0000003c  00000000  00000000  0000019c  2**2
                  CONTENTS, READONLY
  4 .debug_aranges 00000028  00000000  00000000  000001d8  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_info   000008a5  00000000  00000000  00000200  2**0
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_abbrev 000007f7  00000000  00000000  00000aa5  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_line   000002e7  00000000  00000000  0000129c  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_frame  00000048  00000000  00000000  00001584  2**2
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_str    00000420  00000000  00000000  000015cc  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_loc    00000049  00000000  00000000  000019ec  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_ranges 00000018  00000000  00000000  00001a35  2**0
                  CONTENTS, READONLY, DEBUGGING

Disassembly of section .text:

00000000 <__vectors>:
   0:  0c 94 46 00   jmp  0x8c  ; 0x8c <__ctors_end>
   4:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
   8:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
   c:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  10:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  14:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  18:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  1c:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  20:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  24:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  28:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  2c:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  30:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  34:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  38:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  3c:  0c 94 78 00   jmp  0xf0  ; 0xf0 <__vector_15>
  40:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  44:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  48:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  4c:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  50:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  54:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  58:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  5c:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  60:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  64:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  68:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  6c:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  70:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  74:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  78:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  7c:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  80:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  84:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>
  88:  0c 94 50 00   jmp  0xa0  ; 0xa0 <__bad_interrupt>

0000008c <__ctors_end>:
  8c:  11 24         eor  r1, r1
  8e:  1f be         out  0x3f, r1  ; 63
  90:  cf ef         ldi  r28, 0xFF  ; 255
  92:  d0 e1         ldi  r29, 0x10  ; 16
  94:  de bf         out  0x3e, r29  ; 62
  96:  cd bf         out  0x3d, r28  ; 61
  98:  0e 94 52 00   call  0xa4  ; 0xa4 <main>
  9c:  0c 94 8a 00   jmp  0x114  ; 0x114 <_exit>

000000a0 <__bad_interrupt>:
  a0:  0c 94 00 00   jmp  0  ; 0x0 <__vectors>

000000a4 <main>:
#include <util/delay.h>


      int main(void)
      {
        TCNT0 = 0;
  a4:  12 be         out  0x32, r1  ; 50
        TCCR0 &= (~(1<<COM00)) & (~(1<<COM01));  // normal operation mode, OC0 not connected to a pin
  a6:  83 b7         in  r24, 0x33  ; 51
  a8:  8f 7c         andi  r24, 0xCF  ; 207
  aa:  83 bf         out  0x33, r24  ; 51
        TCCR0 |= (1<<WGM01);          // clear on compare matching
  ac:  83 b7         in  r24, 0x33  ; 51
  ae:  88 60         ori  r24, 0x08  ; 8
  b0:  83 bf         out  0x33, r24  ; 51
        TCCR0 &= (~(1<<WGM00));          // with OCR0
  b2:  83 b7         in  r24, 0x33  ; 51
  b4:  8f 7b         andi  r24, 0xBF  ; 191
  b6:  83 bf         out  0x33, r24  ; 51
        TCCR0 |= (1<<CS01);            // set prescaler
  b8:  83 b7         in  r24, 0x33  ; 51
  ba:  82 60         ori  r24, 0x02  ; 2
  bc:  83 bf         out  0x33, r24  ; 51
        TCCR0 &= (~(1<<CS00)) & (~(1<<CS02));  // to 1 -> 12MHz
  be:  83 b7         in  r24, 0x33  ; 51
  c0:  8a 7f         andi  r24, 0xFA  ; 250
  c2:  83 bf         out  0x33, r24  ; 51
        
        OCR0 = 200;                // set compare value for timer0 to 12 (12 * 0.08333µs = 1µs)
  c4:  88 ec         ldi  r24, 0xC8  ; 200
  c6:  81 bf         out  0x31, r24  ; 49

        TIMSK |= (1<<OCIE0);          // enable interrupt for timer0
  c8:  87 b7         in  r24, 0x37  ; 55
  ca:  82 60         ori  r24, 0x02  ; 2
  cc:  87 bf         out  0x37, r24  ; 55
        
        DDRA |= (1<<PA0);
  ce:  d0 9a         sbi  0x1a, 0  ; 26
        DDRD |= (1<<PD1);
  d0:  89 9a         sbi  0x11, 1  ; 17

        sei();
  d2:  78 94         sei
        
        while(1)
        {
          PORTA ^= (1<<PA0);
  d4:  91 e0         ldi  r25, 0x01  ; 1
  d6:  8b b3         in  r24, 0x1b  ; 27
  d8:  89 27         eor  r24, r25
  da:  8b bb         out  0x1b, r24  ; 27
  #else
    //round up by default
    __ticks_dc = (uint32_t)(ceil(fabs(__tmp)));
  #endif

  __builtin_avr_delay_cycles(__ticks_dc);
  dc:  2f ef         ldi  r18, 0xFF  ; 255
  de:  30 e7         ldi  r19, 0x70  ; 112
  e0:  82 e0         ldi  r24, 0x02  ; 2
  e2:  21 50         subi  r18, 0x01  ; 1
  e4:  30 40         sbci  r19, 0x00  ; 0
  e6:  80 40         sbci  r24, 0x00  ; 0
  e8:  e1 f7         brne  .-8        ; 0xe2 <main+0x3e>
  ea:  00 c0         rjmp  .+0        ; 0xec <main+0x48>
  ec:  00 00         nop
  ee:  f3 cf         rjmp  .-26       ; 0xd6 <main+0x32>

000000f0 <__vector_15>:
        return 0;
      }


      ISR(TIMER0_COMP_vect)
      {
  f0:  1f 92         push  r1
  f2:  0f 92         push  r0
  f4:  0f b6         in  r0, 0x3f  ; 63
  f6:  0f 92         push  r0
  f8:  11 24         eor  r1, r1
  fa:  8f 93         push  r24
  fc:  9f 93         push  r25
        PORTD ^= (1<<PD1);
  fe:  92 b3         in  r25, 0x12  ; 18
 100:  82 e0         ldi  r24, 0x02  ; 2
 102:  89 27         eor  r24, r25
 104:  82 bb         out  0x12, r24  ; 18
 106:  9f 91         pop  r25
 108:  8f 91         pop  r24
 10a:  0f 90         pop  r0
 10c:  0f be         out  0x3f, r0  ; 63
 10e:  0f 90         pop  r0
 110:  1f 90         pop  r1
 112:  18 95         reti

00000114 <_exit>:
 114:  f8 94         cli

00000116 <__stop_program>:
 116:  ff cf         rjmp  .-2        ; 0x116 <__stop_program>

[(prx) A. K. (prx)]

M103C Fuse programmiert. Stackpointer zeigt dorthin, wo der M64 RAM hat, 
aber eben nicht der M103C. Erster Interrupt ok, Return geht ab in den 
Wald.

[Anständiger Definer (Gast)]

@MS
Nimm erst den Stock aus deinem ...

CD schrieb über die unübersichtliche Initialisierung. Und warum 
unübersichtlich! Weil durch die 1 << das Auge abgelenkt wird. Viel 
zuviele unnötige Zeichen.

Man kann ein C Programm auch in einer Zeile schreiben. Warum macht man 
das nicht? Denk darüber nach, bevor du wieder mit Puls antwortest.

[Florian C. (flo94)]

@A. K.: was bedeutet das und wie kann dies vermieden werden?


Jeder hat andere Vorlieben und am Ende kann man alle anderen 
Schreibweisen auch nachvollziehen, daher soll doch jeder programmieren 
wie es ihm beliebt, hauptsache man hält sich an Ansi C...

[Zeichenexperte (Gast)]

Anständiger Definer schrieb:
> Viel zuviele unnötige Zeichen.

So wie dein Beitrag.

[Carl D. (jcw2)]

Vektor passt.
Ist das mit -Os übersetzt?
Die ISR scheint mir etwas lang. Aber das ist eben auch ein Chip mit 
H-Kennzeichen. Der kann nicht mal per PIN-Write mit einen Ausgang 
wackeln.
Aber 8*25=200 Takte braucht der nicht für die ISR.
Langsameres delay() ja, aber höchstens 2..3x.

[S. Landolt (Gast)]

Diese M103-Fuse ist (unglücklicherweise) werksseitig programmiert. Um 
einen echten ATmega64A zu haben, muss sie deaktiviert werden.

[Florian C. (flo94)]

@Carl Drexler:
Ich denke auch, dass das Delay nicht deutlich länger sein müsste...

@S. Landolt:
Ok, kann ich diese M103-Fuse einfach in den Fusebits deaktivieren?


Im Anhang befindet sich ein Foto vom Oszillogramm: oben der LED-Ausgang, 
unten der Timer-Interrupt Ausgang...

[(prx) A. K. (prx)]

Florian C. schrieb:
> Ok, kann ich diese M103-Fuse einfach in den Fusebits deaktivieren?

Ja.

[S. Landolt (Gast)]

> Ok, kann ich diese M103-Fuse einfach in den Fusebits deaktivieren?
Ja. Da sie, M103C um korrekt zu sein, im Extended Fuse Byte nur noch 
zusammen mit dem WDTON liegt, kann zumindest nichts schief gehen.

[Carl D. (jcw2)]

Anständiger Definer schrieb:
> @MS
> Nimm erst den Stock aus deinem ...
>
> CD schrieb über die unübersichtliche Initialisierung. Und warum
> unübersichtlich! Weil durch die 1 << das Auge abgelenkt wird. Viel
> zuviele unnötige Zeichen.
>
> Man kann ein C Programm auch in einer Zeile schreiben. Warum macht man
> das nicht? Denk darüber nach, bevor du wieder mit Puls antwortest.

Das ist aber auch nicht wirklich schwer, wenn man will. Seit C11 
(spätestens) sind Bit-Konstanten sogar Standard.

Und eine wie auch immer Abneigung gegen eine Chip-Familie an der Frage
Bit-Nummer oder Bit-Maske festzumachen, dafür bin ich ca 40 Jahre zu 
alt.

Ich benutze selbst lieber mehr als C und hab dann
Avr::Timer0::Wgm = Avr::Timer0::WGM::CTC;
da stehen. Sogar wenn Wgm über 2 HW-Register verteilt ist.

[Florian C. (flo94)]

Im Anhang befinden sich meine Fuse-Bits.
Hier gibt es nirgens das M103 Fusebit... Nach Aktivierung des 
WDTON-Fusebit kam es zu unvorhergesehenem Verhalten im Oszillogramm, 
daher habe ich es wieder deaktiviert, aber das Ergebnis war das Selbe...

[Anständiger Sefiner (Gast)]

Carl D. schrieb:
> Und eine wie auch immer Abneigung gegen eine Chip-Familie an der Frage
> Bit-Nummer oder Bit-Maske festzumachen, dafür bin ich ca 40 Jahre zu
> alt.
Der Chip kann nix dafür, das liegt schon an den Codern. ?

[Volker S. (vloki)]

Florian C. schrieb:
> Im Anhang befindet sich ein Foto vom Oszillogramm: oben der LED-Ausgang,
> unten der Timer-Interrupt Ausgang...

Sieht aus als wäre der Wechsel beim Timer etwas früher.
Der IR killt (wegen der M103C Kompatibilität?) irgendwie die 
Zählvariable des delay Macros?

[S. Landolt (Gast)]

Die nennen das 'CompMode'!

Egal wie es ausgeht, mein Dank an A.K., dass er meiner Erinnerung auf 
die Sprünge geholfen hat.
(Und gleich morgen gehe ich in die Apotheke, vielleicht haben sie ja 
etwas gegen akuten Gedächtnisschwund)

[(prx) A. K. (prx)]

S. Landolt schrieb:
> Die nennen das 'CompMode'!

Ja, ziemlich idiotisch.

> Egal wie es ausgeht, mein Dank an A.K., dass er meiner Erinnerung auf
> die Sprünge geholfen hat.

Hätte er den M128 genommen, wärst du sicherlich gleich drauf gekommen - 
bei dem stolpert(e) wohl jeder mal drüber. Der M64 ist technisch 
gleich, aber halb getestet, folglich hat er auch diese in diesem Fall 
sinnlose Fuse.

[Florian C. (flo94)]

WOW, ES FUNKTIONIERT!!
Vielen vielen Dank, es lag tatsächlich am "CompMode" Fusebit!
Nachdem ich es deaktiviert und gesetzt habe geht jetzt beides 
einwandfrei!

Da wäre ich ja NIE drauf gekommen!

Wieso ist das nur standardmäßig gsetzt, ist ja idiotisch -.-

[(prx) A. K. (prx)]

Florian C. schrieb:
> Wieso ist das nur standardmäßig gsetzt, ist ja idiotisch -.-

Der ATmega128 ist dadurch ein funktionskompatibler Nachfolger vom 
ATMega103. So konnte man den M103 direkt durch den M128 ersetzen, ohne 
etwas ändern zu müssen. Beim M64 ist das bloss ein Schmutzeffekt.

[Florian C. (flo94)]

Trotzdem sollte das eher opt-in sein als standardmäßig gesetzt...

[(prx) A. K. (prx)]

Florian C. schrieb:
> Trotzdem sollte das eher opt-in sein als standardmäßig gesetzt...

Dann wäre er nicht mehr plug-in-compatible gewesen. Sie hätten natürlich 
die Logistik um einen Pseudo-Typ M103A bereichern können, der in der 
abschliessenden Typ-Programmierung anders eingestellt wird als der M128. 
Könnte mir vorstellen, dass es bei Atmel danach Bisspuren am Arsch gab.

Jeder der hier schon länger unterwegs ist kennt das eigentlich. Also 
dass der M128 beim ersten Return nach einem Unterprogrammaufruf 
wegfliegt. Hier wars eben ein Interrupt.

[Florian C. (flo94)]

Ok macht etwas Sinn, aber hätte ich trotzdem nicht so gemacht...

Bin leider selten in diesem Forum und das war mein erster Thread hier, 
also war mir das neu und alle bisherigen µCs die ich programmiert habe 
hatten da keinerlei Probleme...

[Peter D. (peda)]

Florian C. schrieb:
> Wieso ist das nur standardmäßig gsetzt, ist ja idiotisch -.-

Vermutlich gab es einen Kunden, der richtig große Stückzahlen des 
Mega103 abgenommen hat und der hat es Atmel diktieren können.
Und damit auch diese krude SPI-Programmierung über die UART-Pins, wo 
auch viele drauf reinfallen.