Interrupt Vectoren ATmega16a

[Matze T. (gruetzwurschd)]

Hallo Leute,

ich habe momentan Folgendes Problem. Habe die suchfunktion genutzt und 
auch Google fördert nichts brauchbares zu Tage.

Ich benutze derzeit einen ATmega16A und den WinAVR Compiler. Nun habe 
ich das Problem, dass der Compiler den Prozessor unterstützt, aber 
sobald ich in der int_vector-tabelle suche, ist dieser Prozessortyp 
nicht gelistet. Bis dato hatte ich keine Probleme wenn ich die Vektoren 
dennoch benutzt habe:


ISR(INT0_vect) oder ISR(TWI_vect)
funktionier tadellos.

Verwende ich allerdings:
UART_UDRE_vect oder USART0_UDRE_vect
kommt die warningmeldung "../rs232.c:31: warning: 'USART0_UDRE_vect' 
appears to be a misspelled signal handler"

benutze ich hingegen USART_UDRE_vect
kommt zwar kein warning. sobale ich aber sei(); setze wird mir ein Reset 
ausgelöst und ich stehe wieder am Anfang vom Programm.

auch _VECTOR(13) funktioniert auch nicht

ich habe es mit folgendem quellcode probiert.
für Hilfe vielen dank im vorraus
gruß Tarkan

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

void RS232_Init();

int main(void)
{int a;

RS232_Init();
sei();
a=1;

while(1);
}

void RS232_Init()
{

UBRRH = 0x00;
UBRRL = 0x03;  //Entspricht 250kbps bei 16 MHz

UCSRB = (1<<RXEN)|(1<<TXEN)|(1<<UDRIE);//|(1<<RXCIE)|(1<<TXCIE)|(1<<UDRIE);

UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);

}

ISR(_VECTOR(13))//geht nicht
{int a;
a=1;
}

[Falk B. (falk)]

@  Tarkan D. (gruetzwurschd)

>benutze ich hingegen USART_UDRE_vect

Der ist OK.

>kommt zwar kein warning. sobale ich aber sei(); setze wird mir ein Reset
>ausgelöst und ich stehe wieder am Anfang vom Programm.

Woran erkennst du das?

>ich habe es mit folgendem quellcode probiert.

Du musst natürlich Daten in UDR schreiben, sonst bleibt dein Interrupt 
ständig aktiv.

MFG
Falk

[Matze T. (gruetzwurschd)]

Falk Brunner schrieb:
>>kommt zwar kein warning. sobale ich aber sei(); setze wird mir ein Reset
>>ausgelöst und ich stehe wieder am Anfang vom Programm.
>
> Woran erkennst du das?

da erkenne ich am Debuggen daran, dass sobald ich über das sei(); laufe, 
ich sofort wieder am anfang der main-funktion stehe, anstatt in die ISR 
zu kommen :)
zusätlich habe ich breakpoints in der ISR und kann somit sicher sagen, 
dass der code in der ISR nicht ausgeführt wird.

Falk Brunner schrieb:
> Du musst natürlich Daten in UDR schreiben, sonst bleibt dein Interrupt
> ständig aktiv.

da gebe ich dir vollkommen recht, allerdings ist das ja der effekt den 
ich erzielen will, um zu verifizieren ob die ISR ausgeführt wird.

[Matze T. (gruetzwurschd)]

übrigens:

sobald ich an der ISR was ändere kommt auch:

../rs232.c:31: warning: 'USART_UDRE_vect' appears to be a misspelled 
signal handler

[Hc Z. (mizch)]

> sobald ich an der ISR was ändere kommt auch:

> ../rs232.c:31: warning: 'USART_UDRE_vect' appears to be a misspelled
> signal handler

Du solltest auch am Namen der ISR nicht einfach rumprobieren und was 
ändern, sondern säuberlich darauf achten, dass Du nur die Bezeichnungen 
nimmst, die in der Dokumentation zu <avr/interrupt.h> stehen, und zwar 
für Deinen µC-Typ.

Wenn nach sei() ein Reset ausgeführt wird, hast Du einen weiteren 
Interrupt hängen (also erlaubt und seine Bedingung trifft zu), und zwar 
einen, für den Du keine ISR definiert hast.  Ganz sicher weißt Du das, 
wenn Du einen Breakpoint auf __bad_interrupt setzst und der triggert.

[Matze T. (gruetzwurschd)]

Hc Zimmerer schrieb:
> Du solltest auch am Namen der ISR nicht einfach rumprobieren und was
> ändern, sondern säuberlich darauf achten, dass Du nur die Bezeichnungen
> nimmst, die in der Dokumentation zu <avr/interrupt.h> stehen, und zwar
> für Deinen µC-Typ.

ich änder nix am namen, sondern wenn ich statt a=1; a=2; schreibe, kommt 
die warningmeldung beim ersten kompilieren, beim zweiten mal mit 
unveränderter ISR kommt 0 warnings, 0 errors.

Des Weiteren steht in der in der Dokumentation von <avr/interrupt.h> 
rein garnihcts über den ATmega16a, sondern nur über den ATmega16, was 
aber bis jetzt immer wunderbar geklappt hat.

Hc Zimmerer schrieb:
> Wenn nach sei() ein Reset ausgeführt wird, hast Du einen weiteren
> Interrupt hängen (also erlaubt und seine Bedingung trifft zu), und zwar
> einen, für den Du keine ISR definiert hast.

Das ist ja soweit richtig. aber wenn mich nicht alles täuscht sind die 
einzelnen interrupts doch nach einem Reset deaktiviert, außer ich sage 
ausdrücklich sie sollen aktiviert werden(was ich nicht habe).

[Karl H. (kbuchegg)]

Tarkan D. schrieb:

> Des Weiteren steht in der in der Dokumentation von <avr/interrupt.h>
> rein garnihcts über den ATmega16a, sondern nur über den ATmega16, was
> aber bis jetzt immer wunderbar geklappt hat.

Das ist auch egal.
Aus Softwaresicht sind die beiden soweit identisch

> Das ist ja soweit richtig. aber wenn mich nicht alles täuscht sind die
> einzelnen interrupts doch nach einem Reset deaktiviert, außer ich sage
> ausdrücklich sie sollen aktiviert werden(was ich nicht habe).

Mit dem sei() aktivierst du aber den Data Register Empty Interrupt, den 
du vorher eingeschaltet hast.

In der iom16.h steht, wie der wirklich heisst
USART_UDRE_vect

und ja, nach dem sei() feuert der, denn das Data Register ist ja 
wirklich empty. Und der feuert und feuert und feuert.

Das hier

ISR(_VECTOR(13))

solltest du hingegen nicht tun.
Denn der Vector 13 ist mit dem Tx-Complete Interrupt verknüpft. Dadurch 
das du hier den Vector 13 angegeben hast, hast du dir selbst den Data 
Register Empty Interrupt geklaut und damit hast du einen Interrupt 
eingeschaltet, für den du keinen Handler hast - der Bad Interrupt 
schlägt zu und resettet den µC.

Für den Mega16 läuft dieses Programm so wie es programmiert ist. Wenn es 
bei dir nicht tut, oder du vom Compiler Warnungen oder Fehler bekommst, 
dann hast du höchst wahrscheinlich bei den Projektoptionen oder im 
Simulator den falschen Prozessor eingestellt.

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

void RS232_Init();

int main(void)
{int a;

RS232_Init();
sei();
a=1;

while(1);
}

void RS232_Init()
{

UBRRH = 0x00;
UBRRL = 0x03;  //Entspricht 250kbps bei 16 MHz

UCSRB = (1<<RXEN)|(1<<TXEN)|(1<<UDRIE);//|(1<<RXCIE)|(1<<TXCIE)|(1<<UDRIE);

UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);

}

ISR( USART_UDRE_vect )
{int a;
a=1;
}

[Matze T. (gruetzwurschd)]

Karl heinz Buchegger schrieb:
> Das hierISR(_VECTOR(13))
> solltest du hingegen nicht tun.
> Denn der Vector 13 ist mit dem Tx-Complete Interrupt verknüpft. Dadurch
> das du hier den Vector 13 angegeben hast, hast du dir selbst den Data
> Register Empty Interrupt geklaut und damit hast du einen Interrupt
> eingeschaltet, für den du keinen Handler hast - der Bad Interrupt
> schlägt zu und resettet den µC.

Danke für die Antwort. Ich weiß es kling blöd wenn ich jetzt sage dass 
ich alles richtig gemacht habe und alle anderen haben unrecht. Aber ich 
habe hier einen Ausschnitt aus dem Datenblatt des ATmega16a. Also 
entweder ist tatsächlich in der headerfile ein Fehler oder im Datenblatt 
oder ich bin wirklich zu unfähig. Aber hier seht selbst:(hoffe das hat 
geklappt mit dem dateianhang)

[Karl H. (kbuchegg)]

Tarkan D. schrieb:

> ich alles richtig gemacht habe und alle anderen haben unrecht. Aber ich
> habe hier einen Ausschnitt aus dem Datenblatt des ATmega16a.

Das Datenblatt beginnt mit seiner Zählung bei 1
Das Header File beginnt in typischer C-Manier seine Zählung bei 0

Das hat seine Vorteile, wenn man aus der Nummerierung des Vektors die 
Adresse ausrechnenn soll, wo der entsprechende Eintrag in der 
Vektortabelle gemacht werden soll.

Nur musst du auch die Zählweise verwenden, auf die das VECTOR Makro 
ausgelegt ist.

[Matze T. (gruetzwurschd)]

Ich hab jetzt das komplette Projekt gelöscht und nochmal neu aufgezogen.
Hat alle snihct geholfen.

mit ISR( USART_UDRE_vect ) kam das Warning immernoch. ISR wurde nicht 
aufgerufen.


anschließend habe ich es nochmal mit folgendem Quelltext probiert:

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

void RS232_Init();

int main(void)
{int a;

RS232_Init();
sei();
a=1;

while(1);
}

void RS232_Init()
{

UBRRH = 0x00;
UBRRL = 0x03;  //Entspricht 250kbps bei 16 MHz

UCSRB = (1<<RXEN)|(1<<TXEN)|(1<<UDRIE);//|(1<<RXCIE)|(1<<TXCIE)|(1<<UDRIE);

UCSRC = (1<<URSEL)|(1<<USBS)|(3<<UCSZ0);

    }

ISR( _VECTOR(12) )
{int a;
a=1;
}

und... es funktioniert.

ein Blick in die iom16a offenbarte mir folgende Code-Zeilen:

#define USARTUDRE_vect_num  12
#define USARTUDRE_vect      _VECTOR(12)  /* USART Data Register Empty */

das heißt bei USART_UDRE_vect ist der _ zuviel. Das gilt allerdings nur 
für die Vektoren die das USART-Modul und das SPI-Modul betreffen.



Grüße Tarkan

[Karl H. (kbuchegg)]

Tarkan D. schrieb:

> ISR( _VECTOR(12) )
> {int a;
> a=1;
> }[/c]
>
> und... es funktioniert.

Schreib trotzdem USARTUDRE_vect, solange bis der Fehler in der Toolchain 
behoben wurde.

> ein Blick in die iom16a offenbarte mir folgende Code-Zeilen:
>

> #define USARTUDRE_vect_num  12
> #define USARTUDRE_vect      _VECTOR(12)  /* USART Data Register Empty */
>

Da wurde offenbar an der Nomenklatur gedreht. Diese Schreibweise ist 
IMHO nicht richtig.

[Matze T. (gruetzwurschd)]

ja ich werde es in zukunft schon mit dem USARTUDRE_vect machen. Wollte 
nur bescheid sagen, weil ich mit sicherheit nihct der Letzte bin der 
damit Probleme hat.

[Hc Z. (mizch)]

Ich bin gerade dabei, einen Patch für avr-libc zusammenzustellen, der 
Namen erlaubt, die konsistent zum bisherigen Vektor-Schema sind (z.B. 
USART_RXC_vect), die geänderten aber nicht rausschmeißt (so dass in 
Zukunft beides geht).