ich komme nicht mehr weiter es gibt immer einen Vectorfehler: ../usart.c:383: warning: 'USART_RX' appears to be a misspelled signal handler lt. Include soll das Vector 18 sein, aber lt Datenblatt Vector 19 einer von beiden muss falsch liegen kennt das schon einer, habe nix gefunden zu dem Thema ausser das Atmel inkonsistent ist in der Bezeichnung, mal benennen sie jetztz alles mit 0 und 1 für die mega die 2 usart haben, aber auch die die nur einen usart haben, mal nicht in der iomx8 steht #if defined (_AVR_ATmega88_) || defined (_AVR_ATmega168_) /* USART Rx Complete */ #define USART_RX_vect _VECTOR(18) #define SIG_USART_RECV _VECTOR(18) /* USART, Data Register Empty */ #define USART_UDRE_vect _VECTOR(19) #define SIG_USART_DATA _VECTOR(19) aber im mega168 Datenblatt steht: Vector no. Program address(2) Source Interrupt definition 19 0x0024 USART, RX USART Rx complete
Vermutlich muß es heißen USART_RX_vect.
Joachim B. schrieb: > ich komme nicht mehr weiter > > es gibt immer einen Vectorfehler: > ../usart.c:383: warning: 'USART_RX' appears to be a misspelled signal > handler Der Vektor heisst "USART_RX_vect", "USART_RX" kennt er nicht. > lt. Include soll das Vector 18 sein, aber lt Datenblatt Vector 19 > > einer von beiden muss falsch liegen Vektor 1 ist bei Atmel der Reset-Vektor, die Macher vom GCC fangen mit Vektor 1 bei INT0 an zu zählen. Naja falsch. Zumindest ist es immer gleich. > kennt das schon einer, habe nix gefunden zu dem Thema ausser das Atmel > inkonsistent ist in der Bezeichnung, mal benennen sie jetztz alles mit 0 > und 1 für die mega die 2 usart haben, aber auch die die nur einen usart > haben, mal nicht Ich finde das auch bescheuert. Muss man mit leben. > in der iomx8 steht > > #if defined (_AVR_ATmega88_) || defined (_AVR_ATmega168_) > /* USART Rx Complete */ > #define USART_RX_vect _VECTOR(18) > #define SIG_USART_RECV _VECTOR(18) > > /* USART, Data Register Empty */ > #define USART_UDRE_vect _VECTOR(19) > #define SIG_USART_DATA _VECTOR(19) > > aber im mega168 Datenblatt steht: > Vector no. Program address(2) Source Interrupt definition > 19 0x0024 USART, RX USART Rx complete Siehe oben. mfg.
Thomas Eckmann schrieb: > Der Vektor heisst "USART_RX_vect", "USART_RX" kennt er nicht. nehmt die Fehlermeldung nicht so bierernst, da sind ja #defines zwischen ;-) ich habe in der ISR(alle Namen probiert, ändert ja nix am Unterschied 18/19) es geht um die Vectordifferenz das im Include auf Vector 18 gezeigt wird im Datenblatt auf Vector 19 habe gerade ein dejayvu alte Sigma Linsen an neuer Canon Blendensteuerung auch 18/19 gibt error
:
Bearbeitet durch User
Das Datenblatt beginnt die Zählung der Vektoren mit 1, das Include File mit 0. Hast du das "_vect" hinten am Namen vergessen?
Joachim B. schrieb: > Thomas Eckmann schrieb: >> Der Vektor heisst "USART_RX_vect", "USART_RX" kennt er nicht. > > nehmt die Fehlermeldung nicht so bierernst, da sind ja #defines zwischen > ;-) > > ich habe in der ISR(alle Namen probiert, ändert ja nix am Unterschied > 18/19) > > es geht um die Vectordifferenz das im Include auf Vector 18 gezeigt wird > im Datenblatt auf Vector 19 > > habe gerade ein dejayvu > > alte Sigma Linsen an neuer Canon Blendensteuerung auch 18/19 gibt error Und was ist jetzt dein Problem? mfg.
nein ich hatte alle Namen richtig durch und dann die Alias usw. eigendlich egal wie die ISR wirklich heisst, es müsste ja _Vector 19 eingetragen auch funktionieren ? irgendwas soll an der Sprungweite geändert worden sein das es mit dem Interrupt und dem Rücksprung nicht mehr klappt, im Astudio 6 soll die Objectdatei richtig sein, weiss aber nicht ob das zusammenhängt....
Joachim B. schrieb: > nein ich hatte alle Namen richtig durch und dann die Alias usw. > > eigendlich egal wie die ISR wirklich heisst, es müsste ja _Vector 19 > eingetragen auch funktionieren ? tus nicht. Benutze den Namen aus dem Include File iomx8 und gut ists.
1 | ISR( USART_RX_vect ) |
2 | {
|
3 | char c = UDR; |
4 | }
|
:
Bearbeitet durch User
Thomas Eckmann schrieb: >> einer von beiden muss falsch liegen > > Vektor 1 ist bei Atmel der Reset-Vektor, die Macher vom GCC fangen mit > Vektor 1 bei INT0 an zu zählen. Naja falsch. Zumindest ist es immer > gleich. Irgendjemand dachte halt mal, es wäre eine gute Idee, in C-Manier die Nummerierung bei 0 starten zu lassen. Dann passt das ja auch wunderbar zu der Word-Adresse an der der Vector eingetragen werden muss. Die Nummer des Vektors ist automatisch die Adresse, an der der rjmp hin muss. Am Beispiel Mega8
1 | Vector No. Program Address(2) Source Interrupt Definition |
2 | 1 0x000(1) RESET External Pin, Power-on Reset, Brown-out Reset, and Watchdog Reset |
3 | 2 0x001 INT0 External Interrupt Request 0 |
4 | 3 0x002 INT1 External Interrupt Request 1 |
5 | 4 0x003 TIMER2 COMP Timer/Counter2 Compare Match |
6 | 5 0x004 TIMER2 OVF Timer/Counter2 Overflow |
7 | 6 0x005 TIMER1 CAPT Timer/Counter1 Capture Event |
8 | 7 0x006 TIMER1 COMPA Timer/Counter1 Compare Match A |
9 | ... |
Ich finde da eigentlich Atmels Vorgehen inkonsequent, denn an anderen Stellen hatten sie keinerlei Hemmungen, Nummerierungen bei 0 starten zu lassen. Zb Timer Modi
:
Bearbeitet durch User
Karl Heinz schrieb: > Irgendjemand dachte halt mal, es wäre eine gute Idee, in C-Manier die > Nummerierung bei 0 starten zu lassen. Dann passt das ja auch wunderbar > zu der Word-Adresse an der der Vector eingetragen werden muss. Die > Nummer des Vektors ist automatisch die Adresse, an der der rjmp hin > muss. Am Beispiel Mega8 Das passt aber nur bis 8K Flash. Ab Mega168 sind die Vektoren 2 Word lang und dann geht es auch wieder nicht auf. Man hätte die Vektoren auch nach den Planeten von innen nach aussen benennen können. Dann wäre allerdings bei 9 Schluss. Bei neueren Controllern sogar schon bei 8. Aber als C-Programmierer muss man sich darum ja, Gott sei Dank, keine Gedanken machen. mfg.
:
Bearbeitet durch User
Thomas Eckmann schrieb: > Karl Heinz schrieb: >> Irgendjemand dachte halt mal, es wäre eine gute Idee, in C-Manier die >> Nummerierung bei 0 starten zu lassen. Dann passt das ja auch wunderbar >> zu der Word-Adresse an der der Vector eingetragen werden muss. Die >> Nummer des Vektors ist automatisch die Adresse, an der der rjmp hin >> muss. Am Beispiel Mega8 > > Das passt aber nur bis 8K Flash. Ab Mega168 sind die Vektoren 2 Word > lang und dann geht es auch wieder nicht auf. Ja, ich weiß. Drumm soll er ja auch die vorgegebenen Namen benutzen und nicht selbst die vectoren hinschreiben. Damit schiebt er dann die Schuld auf Atmel :-) Schon klar. Das ganze ist ein "Pain in the ass". Zusammen mit so manch anderem, wobei diese Vector-Nummer Sache ja noch harmlos ist. Diese Inkonsistenz mit den UART Nummern wurde ja auch schon angesprochen. Dazu kommt, dass der Vektor bei den älteren Controllern UART_RX_vect (also ohne C für Complete) heißt, bei den neueren mit C, etc. etc. Allerdings: jetzt würde es in Atmels Hand liegen, da mal etwas Ordnung in den Include Files rein zu bringen. Was aber wieder nicht so einfach ist, weil ja in den Datenblättern wieder die alten Namen benutzt werden ..... Wie du so schön gesagt hast >... Muss man mit leben. Dem ist nichts hinzuzufügen.
so keine Fehlermeldungen mehr ABER leider auch keine Funktion, muss erst mal schauen ob nicht irgendwo im Code Schrott ist oder die Hardware nicht mehr mitspielt (heul) Danke
Hardware OK, SW OK, man muss natürlich die Interrupts auch einschalten, Danke, manchmal sieht man den Wald nicht....
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.