ISR geht nicht mehr in Atmel Studio 7 ?

[Markus M. (atmelfreak100)]

Guten Tag, ich habe ein Problem, sehr komisches.

Wenn ich ein neues Projekt erstelle und dort sei(); mache vor der 
while(1) in der Main. Dann wird das rot. Kompilieren kann ich es nicht. 
Klar.
#include <avr/interrupt.h>

eingefügt schon geht das kompilieren. Aber das bleibt dennoch rot 
"undefined reference" wenn man mit der Maus drüber geht.

Mache ich eine ISR ist das Wort ISR nicht lila sondern orange wie bei 
einer Funktion.

Ich nutze Tiny1614 und mache dort eine einfaches Programm:
- Einen Pin auf Eingang und BOTHEDGES ISR
- Einen Pin auf Ausgang

In der ISR toggle ich jetzt den Ausgangspin. Am Eingang liegt ein 
Rechteck an
Entsprechend sollte ich auf dem Ausgang auch ein Rechteck haben.

Passieren tu nichts. Als wären gar keine ISR aktiv oder vorhanden.
Dann mal mit einem Timer gemacht und nur den Ausgangspin getoggelt.
Gleiches ergebnis. Es scheint so, als wäre da was nicht OK seitens des 
AS.
Am Code liegt das definitiv nicht.

[Markus M. (atmelfreak100)]

Hier noch der Code, die Frage kommt eh.

#define F_CPU        20000000UL

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

int main(void)
{
  CPU_CCP = 0xD8;
  CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;
  CPU_CCP = 0xD8;
  CLKCTRL_MCLKCTRLB = 0;

  CPU_CCP = 0xD8;
  WDT.CTRLA = 0;

  PORTB.DIR = 0b11111110;

  //Für den Timer (interrupt)  (1 kHz)
  TCD0.CMPBCLR = 625;
  TCD0.INTCTRL = TCD_OVF_bm;
  TCD0.CTRLB = TCD_WGMODE_ONERAMP_gc;
  TCD0.CTRLA = (TCD_CLKSEL_20MHZ_gc | TCD_CNTPRES_DIV32_gc | TCD_SYNCPRES_DIV1_gc | TCD_ENABLE_bm);

  sei();

    while (1) 
    {
    }
}


ISR(TCD0_OVF_vect)
{
  PORTA.OUT ^= (1<<PIN3_bp);
  TCD0.INTFLAGS = TCD_OVF_bm;
}

[Oliver S. (oliverso)]

Markus M. schrieb:
> Tiny1614

Könnte das Problem sein. Hast du mal geschaut, ob der von deiner 
Studio-Version unterstützt wird?

Oliver

[Markus M. (atmelfreak100)]

Oliver S. schrieb:
> Markus M. schrieb:
>> Tiny1614
>
> Könnte das Problem sein. Hast du mal geschaut, ob der von deiner
> Studio-Version unterstützt wird?
>
> Oliver

Ich nutze den in ca. 60 Projekten. Die ganzen Projekte wo der drin ist, 
da funktioniert es. Kopiere ich dieses Projekt geht das kopierte nicht 
mehr....
Strange oder?

Ich habe die neuste Version Microchip Studio. Wenn ich ein neues Projekt 
anlege wird mir der Tiny1614 ja auch aufgeführt. Ich habe es vorhin 
deinstalliert und neuinstalliert sowie PC neustart. Das ist es auch 
nicht.

Es liegt auch nicht am verwendeten CPU Typ. Ich hatte gerade mal mit 
anderen getestet (Tiny85, Mega328P, Xmega) es ist überall das gleiche. 
sei bleibt rot unterstrichen und ISR wird orange wie eine Funktion. 
Obowhl die avr/interrupt.h eingebunden ist.

HÄ?! Ich kapier das nicht.

[Markus M. (atmelfreak100)]

Um genau zu sein kommt bei sei oder cli folgende Info wenn man mit der 
Maus drüber geht:

Unrecognized symbol. ALT+G to jump to a guess, see a list of several, or 
let IntelliSense try.

[Hugo H. (hugo_hu)]

Zeige mal die Meldungen - in "meinem Microchip-Studio" geht es ohne
Probleme.

.LSS sieht auch gut aus.

[Markus M. (atmelfreak100)]

Hugo H. schrieb im Beitrag #7318337:
> Zeige mal die Meldungen - in "meinem Microchip-Studio" geht es ohne
> Probleme.

Exakt wie bei dir. Das kompilieren geht ja auch.
Aber auch wie bei dir, das ISR ist orange und das sei(); rot 
unterstrichen - ohne Referenz. Kompilieren geht. Spiele ich es auf den 
Chip, geht es nicht.

Ich muss aber eine Korrektur machen:
Seit der Deinstallation, PC Neustart, Neuinstallation, PC Neustart geht 
es wieder alles. Crazy.

[Hugo H. (hugo_hu)]

Scheinbar braucht die "Intellisense-Unterstützung" noch etwas "Reife" 
... :-)

[Markus M. (atmelfreak100)]

Hugo H. schrieb:
> Scheinbar braucht die "Intellisense-Unterstützung" noch etwas "Reife"
> ... :-)

Irgendwie geht das gar nicht.
Jetzt ging es. Anderes Tiny1614 Projekt kompiliert.
Dann wieder zu dem Projekt. Jetzt geht das wieder nicht mehr.
Code läuft erfolgreich durch, auf den Chip gespielt keine IRQ 
funktionieren.
Ich deinstalliere das später noch einmal und erneut installieren wenn 
das dann wieder geht, mache ich die Software fertig und gehe nie wieder 
an das Projekt.
Ich kapier das hier nicht

[Georg M. (g_m)]

> PORTA.OUT ^= (1<<PIN3_bp);

PORTA.OUTTGL = PIN3_bm;

Außerdem muss OUTPUT sein.

[Markus M. (atmelfreak100)]

Georg M. schrieb:
>> PORTA.OUT ^= (1<<PIN3_bp);
>
> PORTA.OUTTGL = PIN3_bm;
>
> Außerdem muss OUTPUT sein.

Das stimmt nicht.
OUT ist korrekt.
Es gibt auch OUTTGL, aber das muss man nicht nehmen, Xor geht es 
genauso. Was würde man nur sonst bei den Megas machen die das nicht so 
schön in STrukturen haben wie die neuen Tiny, Mega und XMEGA :)

[S. Landolt (Gast)]

Das ist zwar so, ändert aber nichts am zweiten Einwand - wo steht das 
Setzen auf OUTPUT für PORTA.Pin3?:
  'OUT ... This configuration only has an effect when the output driver 
(PORTx.DIR) is enabled for the corresponding pin.'

[Markus M. (atmelfreak100)]

S. Landolt schrieb:
> Das ist zwar so, ändert aber nichts am zweiten Einwand - wo steht das
> Setzen auf OUTPUT für PORTA.Pin3?:
>   'OUT ... This configuration only has an effect when the output driver
> (PORTx.DIR) is enabled for the corresponding pin.'

Es steht oben ganz oben drin.

PORTB.DIR = xyz

Wie gesagt, die Software ist FEHLERFREI.
Es geht NICHT. Auch nach neuinstallation, PC neustart usw.
Das Programm von oben läuft nicht auf dem Chip ich kapiere nicht was das 
Problem ist.

[Kaj (Gast)]

Markus M. schrieb:
> die Software ist FEHLERFREI.
Starke Worte. Du scheinst nicht viel Erfahrung im Bereich Software zu 
haben.

[Markus M. (atmelfreak100)]

Kaj schrieb:
> Markus M. schrieb:
>> die Software ist FEHLERFREI.
> Starke Worte. Du scheinst nicht viel Erfahrung im Bereich Software zu
> haben.

Ja dann sag mir bitte wo der Fehler liegt. Du weißt ja scheinbar 
bescheid.
Spiele ich die Software wie unten angegeben auf, habe ich an PA2 das 
toggeln in hoher Frequenz. Die ISR macht nichts.

Gestern lief genau das gleiche Programm auch mit der ISR. Dann wieder 
nicht mehr. Den gleichen Code vom Timer nutze ich in 60 anderen Tiny1614 
Projekten ohne Fehler.

Wo ist der Fehler ?!?!

#define F_CPU        20000000UL

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

int main(void)
{
  CPU_CCP = 0xD8;
  CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;
  CPU_CCP = 0xD8;
  CLKCTRL_MCLKCTRLB = 0;

  CPU_CCP = 0xD8;
  WDT.CTRLA = 0;

  PORTA.DIR = 0xFF;
  PORTB.DIR = 0b11111110;

  //Für den Timer (interrupt)  (1 kHz)
  TCD0.CMPBCLR = 625;
  TCD0.INTCTRL = TCD_OVF_bm;
  TCD0.CTRLB = TCD_WGMODE_ONERAMP_gc;
  TCD0.CTRLA = (TCD_CLKSEL_20MHZ_gc | TCD_CNTPRES_DIV32_gc | TCD_SYNCPRES_DIV1_gc | TCD_ENABLE_bm);

  sei();

  while (1)
  {
    PORTA.OUT ^= (1<<PIN2_bp);
  }
}


ISR(TCD0_OVF_vect)
{
  PORTA.OUT ^= (1<<PIN3_bp);
  TCD0.INTFLAGS = TCD_OVF_bm;
}

[Markus M. (atmelfreak100)]

Noch ein Nachtrag, aus Verzweifelung habe ich jetzt mal in die Loop 
folgendes gemacht:

if (TCD0.INTFLAGS)
    {
      PORTA.OUT ^= (1<<PIN2_bp);
      TCD0.INTFLAGS = TCD_OVF_bm;
    }

Ich bekomme dann ein 1khz Signal an PA2. Das heißt die Timerhardware 
funktioniert. Entweder werden keine ISR global aktiviert über das sei() 
oder er sieht die ISR Routine im Compiler nicht.

In das ISR geht er auf jeden Fall nicht, auch im Debug erreicht er die 
nicht.
Wie kann ich prüfen ob sei global aktiviert ist, kann man da ein Bit 
abfragen?
Ich habe eher das Gefühl das der Compiler aber die ISR nicht sieht.


Hier mal der Auszug aus dem Dissembly. Ist das korrekt das da "no source 
file" steht?!

--- No source file -------------------------------------------------------------
00000069  LDD R24,Z+4    Load indirect with displacement 
0000006A  EOR R24,R25    Exclusive OR 
0000006B  STD Z+4,R24    Store indirect with displacement 
0000006C  RJMP PC-0x0003    Relative jump 
0000006D  PUSH R1    Push register on stack 
0000006E  PUSH R0    Push register on stack 
0000006F  IN R0,0x3F    In from I/O location 
00000070  PUSH R0    Push register on stack 
00000071  CLR R1    Clear Register 
00000072  PUSH R24    Push register on stack 
00000073  PUSH R25    Push register on stack 
00000074  PUSH R30    Push register on stack 
00000075  PUSH R31    Push register on stack 
00000076  LDI R30,0x00    Load immediate 
00000077  LDI R31,0x04    Load immediate 
00000078  LDD R25,Z+4    Load indirect with displacement 
00000079  LDI R24,0x08    Load immediate 
0000007A  EOR R24,R25    Exclusive OR 
0000007B  STD Z+4,R24    Store indirect with displacement 
0000007C  LDI R24,0x01    Load immediate 
0000007D  STS 0x0A8D,R24    Store direct to data space 
0000007F  POP R31    Pop register from stack 
00000080  POP R30    Pop register from stack 
00000081  POP R25    Pop register from stack

[Bastler (Gast)]

Ist es nicht so, dass mit "cli" interrupt aktiviert werden?

[Markus M. (atmelfreak100)]

Ich habe das Problem gefunden. unglaublich. Es war das neue Tiny_DFP 
installiert (Version 2.xx). Ich habe es auf 1.3 gesetzt im General unter 
Assembler und Directions unter AVR/GNU C Compiler und schon geht mein 
Code wieder wie er soll!

$(PackRepoDir)\atmel\ATtiny_DFP\1.3.172\include


Verstehe tu ich das zwar dennoch nicht weil es mit dem neuen ja auch 
gehen sollte? Zumindest geht es aber nun

Edit:
Es ging 1x. Erneuter Compilierung geht der unveränderte Code wieder 
nicht...

[Johann L. (gjlayde)]

> CPU_CCP = 0xD8;
> CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;

Nur um ganz sicher zu gehen, dass das Timing eingehalten wird, evtl. in 
Betracht ziehen, stattdessen:

_PROTECTED_WRITE (CLKCTRL_MCLKCTRLA, CLKCTRL_CLKSEL_OSC20M_gc);

und dito für die anderen CCP-geschützten Register.

Das ist ein Makro innerhalb von avr/io.h, das adäquaten (inline 
Assembly) Code erzeugt.

[S. Landolt (Gast)]

>> wo steht das Setzen auf OUTPUT für PORTA.Pin3?
> Es steht oben ganz oben drin.
> PORTB.DIR = xyz
> Wie gesagt, die Software ist FEHLERFREI.

In der ISR steht
> PORTA.OUT ^= (1<<PIN3_bp);

Könnten Sie das einem ATtiny1614-Nichtkenner erläutern?

[Markus M. (atmelfreak100)]

Johann L. schrieb:
>> CPU_CCP = 0xD8;
>> CLKCTRL_MCLKCTRLA = CLKCTRL_CLKSEL_OSC20M_gc;
>
> Nur um ganz sicher zu gehen, dass das Timing eingehalten wird, evtl. in
> Betracht ziehen, stattdessen:
>
>

> _PROTECTED_WRITE (CLKCTRL_MCLKCTRLA, CLKCTRL_CLKSEL_OSC20M_gc);
>

> und dito für die anderen CCP-geschützten Register.
>
> Das ist ein Makro innerhalb von avr/io.h, das adäquaten (inline
> Assembly) Code erzeugt.

Leider kein Unterschied. Das CCP vorweg (siehe Code) sollte das gleiche 
machen das man protected schreibt. Ich habe ja auch die 20Mhz/2 in der 
Loop vom Ausgangspin Toggle und auch bei Loop-Abfrage mit dem Timer 
1khz. Das System läuft und passt. Die ISR Routine sieht der irgendwie im 
Compiler nicht

[Markus M. (atmelfreak100)]

S. Landolt schrieb:
>>> wo steht das Setzen auf OUTPUT für PORTA.Pin3?
>> Es steht oben ganz oben drin.
>> PORTB.DIR = xyz
>> Wie gesagt, die Software ist FEHLERFREI.
>
> In der ISR steht
>> PORTA.OUT ^= (1<<PIN3_bp);
>
> Könnten Sie das einem ATtiny1614-Nichtkenner erläutern?

Was genau jetzt?

PORTx.DIR setzt das Register ob Eingang oder Ausgang. Bei Tiny/Mega 
früher war es das normale DDRx. Das ist einfach nur in Strukturen wie 
bei den Xmegas was ich deutlich besser finde.

PORTx.OUT ist wie früher das PORTx. Also Zugriff ob Low or High.
Es gibt noch Strukturen fürs direkte Setzen (PORTx.CLRSET oder 
PORTx.OUTSET) ich nutze aber primär OUT und mache dann ganz normal damit 
setzen, löschen oder togglen. Die XOR Verknüpfung dort hat nichts mit 
den Tiny zu tun ist ganz normale Toggle per Bitmanipulation.

Sonst haben die Pins eigene Strukturen zum aktivieren für Pullup oder 
Pin Interrupt usw. das geht dann mit PORTx.PINy_CNTR

[S. Landolt (Gast)]

> Was genau jetzt?

Meine Frage ist, ob es da eine interne Korrelation zwischen PORTA und 
PORTB gibt.

[Markus M. (atmelfreak100)]

S. Landolt schrieb:
>> Was genau jetzt?
>
> Meine Frage ist, ob es da eine interne Korrelation zwischen PORTA und
> PORTB gibt.

Setzen tu ich nur Pin3 von PortA in der ISR.
PORTB ist da nicht. ich habe nur bei er Init PORTA + PORTB komplett als 
Ausgang geschaltet außer PB0 als Eingang.

 PORTA.DIR = 0xFF;
  PORTB.DIR = 0b11111110;

[S. Landolt (Gast)]

Okay, das war heute um 12:12 Uhr - da war ich in der Pause.

[S. Landolt (Gast)]

PS: Diese Antwort war von 11:56:

> Es steht oben ganz oben drin.
> Wie gesagt, die Software ist FEHLERFREI.

Und da war die Software nicht fehlerfrei.

[Georg M. (g_m)]

> ISR geht nicht mehr in Atmel Studio 7 ?

Probiere es dann doch mit der MPLAB X IDE.


Aber ich bekomme keine Probleme mit dem Microchip Studio und seinem 
Compiler.
Die LED blinkt. Und sogar sehr schnell.

/*-----------------------------------------------
   ATtiny824 TCB0 50ms periodic interrupt

     VDD 1|‾‾‾‾‾‾‾|14 GND 
     PA4 2|       |13 PA3 ---- LED
     PA5 3|       |12 PA2
     PA6 4|       |11 PA1 
     PA7 5|       |10 UPDI
     PB3 6|       | 9 PB0 
     PB2 7|_______| 8 PB1 

  2MHz/2/50000 = 20Hz    T = 50ms
---------------------------------------------*/

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

ISR(TCB0_INT_vect)
{
  PORTA.OUTTGL = PIN3_bm;         // toggle PA3
  TCB0.INTFLAGS = TCB_CAPT_bm;    // clear TCB0 interrupt flag
} 

int main(void)
{
  _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_10X_gc | CLKCTRL_PEN_bm);    // Main Clock 2MHz

  PORTA.DIRSET = PIN3_bm;                              // PA3 as output

  TCB0.CCMP = 0xC350;                                  // Timeout value (50000)
  TCB0.CTRLA = TCB_CLKSEL_DIV2_gc | TCB_ENABLE_bm;     // TCB0 Clock 1MHz, enable TCB0
  TCB0.INTCTRL = TCB_CAPT_bm;                          // Enable Capture or Timeout interrupt

  sei();                                               // Enable Global Interrupts

  while(1) 
  {
   ;
  }
}

[S. Landolt (Gast)]

> Gestern lief genau das gleiche Programm auch mit der ISR.
> Dann wieder nicht mehr. Den gleichen Code vom Timer nutze
> ich in 60 anderen Tiny1614 Projekten ohne Fehler.

Allmählich entsteht der Verdacht, dass Irgendwas/wer Programmversionen 
durcheinanderwirft.
  Denn das ursprüngliche Programm kann so wie gezeigt nie gelaufen sein, 
auch nicht nach einer Neuinstallation:

> Seit der Deinstallation, PC Neustart, Neuinstallation,
> PC Neustart geht es wieder alles. Crazy.

[Markus M. (atmelfreak100)]

S. Landolt schrieb:
>> Gestern lief genau das gleiche Programm auch mit der ISR.
>> Dann wieder nicht mehr. Den gleichen Code vom Timer nutze
>> ich in 60 anderen Tiny1614 Projekten ohne Fehler.
>
> Allmählich entsteht der Verdacht, dass Irgendwas/wer Programmversionen
> durcheinanderwirft.
>   Denn das ursprüngliche Programm kann so wie gezeigt nie gelaufen sein,
> auch nicht nach einer Neuinstallation:
>
>> Seit der Deinstallation, PC Neustart, Neuinstallation,
>> PC Neustart geht es wieder alles. Crazy.

Verstehe ich nicht ganz. Was genau ist gemeint?
Das Programm lief per Timer im ISR. Und das Programm was ich da gepostet 
habe in einem weiter unterem Kommentar, das lief und läuft jetzt nicht 
mehr. Er springt einfach nicht in die ISR. Als würde die gar nicht 
existieren.

[S. Landolt (Gast)]

> Verstehe ich nicht ganz. Was genau ist gemeint?

? - Was ist an dem Satz "Denn das ursprüngliche Programm kann so wie 
gezeigt nie gelaufen sein" nicht zu verstehen? Dort wird PORTA.DIR nicht 
gesetzt, trotzdem soll PORTA.OUT funktioniert haben, nach einer 
Neuinstallation - das passt nicht zusammen.

[Markus M. (atmelfreak100)]

S. Landolt schrieb:
>> Verstehe ich nicht ganz. Was genau ist gemeint?
>
> ? - Was ist an dem Satz "Denn das ursprüngliche Programm kann so wie
> gezeigt nie gelaufen sein" nicht zu verstehen? Dort wird PORTA.DIR nicht
> gesetzt, trotzdem soll PORTA.OUT funktioniert haben, nach einer
> Neuinstallation - das passt nicht zusammen.

Verstehe. das ursprüngliche da fehlte PORTA.DIR = 0xFF.
Das war drin. ich hatte mal die Pins gewechselt. Nicht verunsichern 
dadurch.
Das programm wie gepostet geht natürlich nicht. unabhängig davon muss er 
ja in den Breakpoint springen und das tut er halt auch nicht.

[Markus M. (atmelfreak100)]

Georg M. schrieb:
>> ISR geht nicht mehr in Atmel Studio 7 ?
> #include <avr/io.h>
> #include <avr/interrupt.h>
>
> ISR(TCB0_INT_vect)
> {
>   PORTA.OUTTGL = PIN3_bm;         // toggle PA3
>   TCB0.INTFLAGS = TCB_CAPT_bm;    // clear TCB0 interrupt flag
> }
>
> int main(void)
> {
>   _PROTECTED_WRITE(CLKCTRL.MCLKCTRLB, CLKCTRL_PDIV_10X_gc |
> CLKCTRL_PEN_bm);    // Main Clock 2MHz
>
>   PORTA.DIRSET = PIN3_bm;                              // PA3 as output
>
>   TCB0.CCMP = 0xC350;                                  // Timeout value
> (50000)
>   TCB0.CTRLA = TCB_CLKSEL_DIV2_gc | TCB_ENABLE_bm;     // TCB0 Clock
> 1MHz, enable TCB0
>   TCB0.INTCTRL = TCB_CAPT_bm;                          // Enable Capture
> or Timeout interrupt
>
>   sei();                                               // Enable Global
> Interrupts
>
>   while(1)
>   {
>    ;
>   }
> }
> [/c]

Jop, genau das gleiche wie bei meinem programm. Es passiert halt nichts 
?!

HILFE!!

Ich bin am verzweifeln.
Kannst du mir bitte noch einmal deine Settings des Projektes - oder noch 
besser das ganze Projekt mal hochladen als ZIP

[Georg M. (g_m)]

Markus M. schrieb:
> Es passiert halt nichts

Und keine Fehlermeldung?

Es gibt nämlich Differenzen:

tinyAVR® 0,1: TCB_CLKSEL_CLKDIV2_gc
tinyAVR®  2 : TCB_CLKSEL_DIV2_gc

[Markus M. (atmelfreak100)]

Georg M. schrieb:
> Markus M. schrieb:
>> Es passiert halt nichts
>
> Und keine Fehlermeldung?
>
> Es gibt nämlich Differenzen:
>
> tinyAVR® 0,1: TCB_CLKSEL_CLKDIV2_gc
> tinyAVR®  2 : TCB_CLKSEL_DIV2_gc

Ich hatte das angepasst. (1<<2)

[Georg M. (g_m)]

Markus M. schrieb:
> Kannst du mir bitte noch einmal deine Settings des Projektes - oder noch
> besser das ganze Projekt mal hochladen als ZIP

ATtiny824 TCB periodic interrupt

[Hugo H. (hugo_hu)]

S. Landolt meint (wie Du sicher auch weisst) das:

Markus M. schrieb:
> CPU_CCP = 0xD8;
>   WDT.CTRLA = 0;

>   PORTB.DIR = 0b11111110;

>   //Für den Timer (interrupt)  (1 kHz)
>   TCD0.CMPBCLR = 625;
>   TCD0.INTCTRL = TCD_OVF_bm;

Da wird nur PORTB gesetzt - habe ich nicht darauf geachtet, weil Du ja 
von einem Compilier-Problem geschrieben hast.
Das gibt es nach wie vor bei mir nicht - auch die ISR wird korrekt 
angesprungen (wie zu sehen ist auch im internen Debugger) es passiert 
halt logischerweise nichts am PIN.
Das Interrupt-Flag muss man übrigens nicht zurücksetzen, das macht der 
Interrupt-Handler.

[Markus M. (atmelfreak100)]

Hugo H. schrieb:
> S. Landolt meint (wie Du sicher auch weisst) das:
> Da wird nur PORTB gesetzt - habe ich nicht darauf geachtet, weil Du ja
> von einem Compilier-Problem geschrieben hast.
> Das gibt es nach wie vor bei mir nicht - auch die ISR wird korrekt
> angesprungen (wie zu sehen ist auch im internen Debugger) es passiert
> halt logischerweise nichts am PIN.
> Das Interrupt-Flag muss man übrigens nicht zurücksetzen, das macht der
> Interrupt-Handler.

Genau, etwas weiter im Verlauf ist das PRogramm gepostet, womit ich nur 
gearbeitet habe. Ich habe das obere korrigiert.

[Markus M. (atmelfreak100)]

Georg M. schrieb:
> Markus M. schrieb:
>> Kannst du mir bitte noch einmal deine Settings des Projektes - oder noch
>> besser das ganze Projekt mal hochladen als ZIP
>
> ATtiny824 TCB periodic interrupt

mit MPLAB geht es auch nicht. Habe dort auch extra kein GNU gewählt. Ich 
tausche gleich mal den Chip ob es an dem liegt. Kann doch nicht sein 
hier.

[Hugo H. (hugo_hu)]

Ich muss mich korrigieren - beide Versionen funktionieren im internen 
Debugger, eine halt mit "undefinierter PORT-Einstellung" (im 
tri-state?).

[Markus M. (atmelfreak100)]

HEUREKA es geht!

Nachdem ich den Chip getauscht habe, ging es. Software drauf, ging. Dann 
meine echte Firmware (das oben ist ja nur Testprogramm) ging wieder 
nicht. Chip wieder runter, neuer drauf. Gleiches. Ging wieder. Dann habe 
ich die Fuses verglichen und warum auch immer ist bei BOOTEND = 0x02 
reingekommen das muss auf 0x00 sein, wie das sonst auch in meinen 
projekten überall der Fall ist.

Sobald das auf 0x02 ist, geht es nicht mehr. Wenn das auf 0x00 ist, geht 
es wie gewünscht!

[S. Landolt (Gast)]

Hugo Hurtig meinte um 14:54:
> Das Interrupt-Flag muss man übrigens nicht zurücksetzen,
> das macht der Interrupt-Handler.

Bei einem ATtiny1614, stimmt das? Kann ich aus dem Datenblatt nicht 
herauslesen.

[Hugo H. (hugo_hu)]

S. Landolt schrieb:
> Bei einem ATtiny1614, stimmt das? Kann ich aus dem Datenblatt nicht
> herauslesen.

Da bin ich wohl "XMEGA-versaut".

Ich so auch nicht, im Debugger passiert es nicht und einen Tiny1614 habe 
ich nicht - nehme es also zurück.

[Markus M. (atmelfreak100)]

Hugo H. schrieb:
> S. Landolt schrieb:
>> Bei einem ATtiny1614, stimmt das? Kann ich aus dem Datenblatt nicht
>> herauslesen.
>
> Da bin ich wohl "XMEGA-versaut".
>
> Ich so auch nicht, im Debugger passiert es nicht und einen Tiny1614 habe
> ich nicht - nehme es also zurück.

Bei den alten Mega/Tinys macht das der Handler.

Bei Xmega muss man es selber machen
Bei den neuen Tiny0,1,2 oder Mega0,1 Series muss man es auch selber 
machen (zumindest hier noch so in Erinnerung als ich damals als die 
rauskamen meine Libs geschrieben habe für das ganze Peripherie Zeug)

[Markus M. (atmelfreak100)]

S. Landolt schrieb:
> Hugo Hurtig meinte um 14:54:
>> Das Interrupt-Flag muss man übrigens nicht zurücksetzen,
>> das macht der Interrupt-Handler.
>
> Bei einem ATtiny1614, stimmt das? Kann ich aus dem Datenblatt nicht
> herauslesen.

Soweit ich es in Erinnerung habe muss man bei den Tiny0,1,2 Series das 
selber machen?

[Hugo H. (hugo_hu)]

Markus M. schrieb:
> Bei Xmega muss man es selber machen

Nein, siehe Bild