mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Interrupt Vectoren ATmega16a


Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
}

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
übrigens:

sobald ich an der ISR was ändere kommt auch:

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

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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;
}

Autor: Tarkan D. (gruetzwurschd)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tarkan D. (gruetzwurschd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.