Hallo, ich hab einen mega1284p und wollte den UART mal zum Laufen bringen. Ich hab die Libary von P Fleury genommen und den mega1284p eingetragen, was aber wohl nicht funktioniert. Ich bekomm aus dem UART nichts raus und habe folgende Warnmeldungen: Warning 1 'SIG_USART_RECV' appears to be a misspelled signal handler xxxx\uart.c 243 1 Warning 2 'SIG_USART_DATA' appears to be a misspelled signal handler xxxx\uart.c 286 1 Warning 3 'SIG_USART1_RECV' appears to be a misspelled signal handler xxxx\uart.c 475 1 Warning 4 'SIG_USART1_DATA' appears to be a misspelled signal handler xxxx\uart.c 510 1 Warning 5 #warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed" Mein Code und die uart.c liegen in den Anhängen: Viele Grüße Tim
Deinen Code braucht man dazu nicht, wenn man sich die Mühe macht zu lesen was der Compiler ausspuckt.. http://www.atmel.com/dyn/resources/prod_documents/doc8059.pdf (Seite 60/61) und Warning 5 überlass ich mal deinem Hausverstand und Google.. Hatte eigtl. schon die gesamte Antwort inkl. Problemlösung hier stehen, aber Faulheit soll man nicht auch noch unterstützen, finds selbst raus, anders lernt man nichts..
Warnung 5 ist schon klar, google spuckt bei den anderen nichts sinnvolles aus Die Vectoren stimmen nicht überein? Sorry, aber für nen Anfänger spuckt google echt nichts interessantes aus
http://www.google.at/#sclient=psy-ab&hl=de&site=&source=hp&q=appears+to+be+a+misspelled+signal+handler&pbx=1&oq=appears+to+be+a+misspelled+signal+handler&aq=f&aqi=g-L1&aql=&gs_sm=e&gs_upl=558l558l0l822l1l1l0l0l0l0l108l108l0.1l1l0&bav=on.2,or.r_gc.r_pw.,cf.osb&fp=107b95f0396d2de5&biw=1680&bih=900 Und der Link den ich dir gegeben hab ist das Datenblatt deines Controllers, auf Seite 60 und 61 steht wie die Vektoren richtig heißen Tim schrieb: > Warning 1 'SIG_USART_RECV' appears to be a misspelled signal handler > xxxx\uart.c 243 1 wird sich beheben indem du an entsprechender Stelle USART0_RX_vect schreibst (die Spalte Source aus dem Datenblatt und hinten das _vect noch dran...) Versuch doch mal die gesamte USART selbst auszuprogrammieren, wenn du Anfänger bist ist das tödlich wenn du fertigen Code verwendest und nicht ansatzweise weißt was passiert und hier wirst du nur auf Widerwillen stoßen, wenn man nicht bereit ist sich selbst in die Thematik einzulesen ;) Schau hier auch das Tutorial an, da steht speziell für Anfänger alles was du brauchst... Solange du solche normalerweise einfache Probleme nicht in den Griff bekommst würd ich keine Library angreifen sondern alles selbst schreiben - dauert, kostet Nerven aber rentiert sich im Endeffekt
das sind aber die Interrupts für das Anzeigen einer fertigen Übertragung^^ und nicht die gesuchten für das eintreffen der ersten Nachricht
Horst schrieb im Beitrag #2523156: > Tim ist nicht nur faul sondern auch noch geistig behindert. Aber man > darf solche Leute ja nicht diskriminieren. Host, dein Geburtsdatum passt in eine Zeit, wo ebensolche Namen vegeben wurden.
tja, darauf bin ich schon selber auch gekommen, es funktioniert aber auch nicht, wenn man in der uart.c die SIG_USART0_RECV durch USART0_RX_vect und so weiter erstzt. Am Montag kann ich mit dem Oszi mal nachschauen, aber das Multimeter zeigt mir auch eine konstante DC Spannung von etwa 9V am Pin2 meiner RS232 Schnittstelle (hängt an einem MAX232
Solange du die Warnungen nicht wegkriegst, kannst du dein Oszi wegpacken. Da sind einfach nur die Interrupt Namen für deinen µC falsch. http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#ISR (Und man beachte auch, dass in dem Code noch die alte SIGNAL Notation verwendet wird und nicht die 'neuere' ISR Notation)
die hab ich ausgetauscht^^, Warnungen sind verschwunden, der ganze Rest passt aber nach Liste die ich in Google gefunden hab, daher versteh ichs nicht, wieso das senden einfach nicht klappt. das Oszi zeigt einen dauernden Highpegel mit 5V, also ist das Teil inaktiv Pins sind alle auf Ausgang gesetzt, Daten empfangen will ich ja noch garnet
Fuses für AVR 1284p richtig gesetzt? schrieb im Beitrag #2525237: > die hab ich ausgetauscht^^ Wie genau hast du das gemacht? Du hast gesehen, dass der Code in uart.c schon für den 1284P vorbereitet ist?
^^ das hab ich hinzugeschrieben, ursprünglich stands nicht drinne. Ich bin nach den Namen in der iom1284p.h gegangen Also, konkrat hab ich: #define UART0_TRANSMIT_INTERRUPT SIG_USART_DATA mit #define UART0_TRANSMIT_INTERRUPT USART0_RXC_vec ersetzt __________________________________________________ #define UART0_TRANSMIT_INTERRUPT SIG_UART0_DATA mit #define UART0_TRANSMIT_INTERRUPT USART0_TX_vect Denke, das war richtig? Gruß Tim
Ich habs mir jetzt nochmal bisschen angeschaut. in der IOM1284 stehen folgende Vektoren:
1 | #define USART0_RX_vect _VECTOR(20) /* USART0, Rx Complete */ |
2 | #define USART0_UDRE_vect _VECTOR(21) /* USART0 Data register Empty */ |
3 | #define USART0_TX_vect _VECTOR(22) /* USART0, Tx Complete */ |
Mein Code in der uart.c
1 | #elif defined(__AVR_ATmega1284P__)
|
2 | /* ATmega with two USART */
|
3 | #define ATMEGA_USART0
|
4 | #define ATMEGA_USART1
|
5 | #define UART0_RECEIVE_INTERRUPT USART0_RX_vect
|
6 | #define UART1_RECEIVE_INTERRUPT USART1_RX_vect
|
7 | #define UART0_TRANSMIT_INTERRUPT USART0_UDRE_vect
|
8 | #define UART1_TRANSMIT_INTERRUPT USART1_UDRE_vect
|
9 | #define UART0_STATUS UCSR0A
|
10 | #define UART0_CONTROL UCSR0B
|
11 | #define UART0_DATA UDR0
|
12 | #define UART0_UDRIE UDRIE0
|
13 | |
14 | #define UART1_STATUS UCSR1A
|
15 | #define UART1_CONTROL UCSR1B
|
16 | #define UART1_DATA UDR1
|
17 | #define UART1_UDRIE UDRIE1
|
Ich hab langsam den Verdacht, dass der Controller in dieser Funktion hängen bleibt, ich verstehs nur nicht ganz wieso:
1 | void uart_puts(const char *s ) |
2 | {
|
3 | while (*s) |
4 | uart_putc(*s++); |
5 | |
6 | }/* uart_puts */ |
Die Funktion ist ja wieder abhängig von dieser
1 | void uart_putc(unsigned char data) |
2 | {
|
3 | unsigned char tmphead; |
4 | |
5 | |
6 | tmphead = (UART_TxHead + 1) & UART_TX_BUFFER_MASK; |
7 | |
8 | while ( tmphead == UART_TxTail ){ |
9 | ;/* wait for free space in buffer */ |
10 | }
|
11 | |
12 | UART_TxBuf[tmphead] = data; |
13 | UART_TxHead = tmphead; |
14 | |
15 | /* enable UDRE interrupt */
|
16 | UART0_CONTROL |= _BV(UART0_UDRIE); |
17 | |
18 | }/* uart_putc */ |
Ich vermute, dass es an diesem Codeteil liegt, was haltet ihr davon?
1 | UART_TxBuf[tmphead] = data; |
2 | UART_TxHead = tmphead; |
3 | |
4 | /* enable UDRE interrupt */
|
5 | UART0_CONTROL |= _BV(UART0_UDRIE); |
Grüße Tim
Tim schrieb: > Ich hab langsam den Verdacht, dass der Controller in dieser Funktion > hängen bleibt, ich verstehs nur nicht ganz wieso: Weil du versuchst, haufenweise Zeugs in einer ISR zu senden.
das ist die Senderoutine von P Fleury und die funktioniert normalerweiße selbst auf den kleineren ATmega. Ich würde zwar eher den Vector UART0_TEX_vect nehmen, aber das scheint ja laut google ein paar probleme zu machen. Ich würd auch auf die Register tippen, habs mir aber mal in der avr libc durchgeschaut und da hab ich keine mit ner Erweiterung von 0 und 1 gefunden Gruß Vandensar und ärger dich nicht über das, dass es nicht geht
vandersar schrieb: > Ich würd auch auf die Register tippen, Ich würde vor allen Dingen erst mal ein einfaches Testprogramm schreiben. (Und könnte mich immer noch in den Allerwertesten beissen, mir sein Programm nicht angesehen zu haben). Wenn man etwas in Betrieb nimmt, dann fängt man nicht gleich mit dem kompliziertesten Fall an, sondern macht erst mal ein ganz einfaches Beispiel um zu sehen ob die Lib grundsätzlich funktioniert. Erst dann kommen die Fehler, die man bei der Verwendung machen kann dazu. Und Stefan hat recht: Die Verwendung in einer ISR ist gaaaaanz schlecht. Denn das gibt einen sauberen Deadlock.
@Thomas Ich hab jetzt deinen Rat befolgt und es selbst programmiert und siehe da, es funktioniert. Das ganze hat mich jetzt ein paar Stunden gekostet, wer den code will, kriegt ihn :-)
Und gelernt hast du auch noch was dabei ;) Wobei die Fleurylib normal wirklich gut ist, hab mich aber mit diesem speziellen Problem hier zugegebenermaßen nicht näher beschäftigt...
Thomas Bergmüller schrieb: > Und gelernt hast du auch noch was dabei ;) > > Wobei die Fleurylib normal wirklich gut ist, hab mich aber mit diesem > speziellen Problem hier zugegebenermaßen nicht näher beschäftigt... Die Fleury Lib puffert Ausgaben und gibt sie nach und nach interrupt gesteuert über die UART aus. Dadurch braucht das Hauptprogramm nicht auf die UART warten, sofern es nicht zuviel in zu kurzer Zeit rausbläst. Passiert das, dann wartet die Zeichenausgabe, bis im Puffer Platz wird. Nur leider, leider. In einer ISR kommen keine anderen Interrupts durch. Die Ausgabefunktion wartet bis zum St. Nimmerleinstag darauf, dass Transmit-Completed Interrupts etwas Platz im Puffer schafffen, was aber nicht passiert, weil - Interrupts in einer ISR ja gesperrt sind. Eigentlich ganz einfach. Und wenn man sich an die Grundregel hält "In einer ISR wird nichts zeitaufwändiges gemacht, vor allen Dingen keine Ausgaben auf LCD oder UART", dann ist das auch überhaupt kein Problem.
Im Xmega mit mehreren Interruptlevels (oder Oldschool mit 8051 is glaub ich auch gegangen wenn ich mich recht erinnere?) würds vermutlich besser hinhaun... Ich handhabs mit ISRs immer so dass Flags gesetzt werden und in der Main abgearbeitet wird. Allerdings Acknowledges und Kommandoantworten sende ich ab und zu auch innerhalb der ISR wenns schnell genug geht. Hab ich - bis jetzt - noch keine Probleme damit gehabt, ist aber zugegebenermaßen vermutlich relativ dünnes Eis..
Thomas Bergmüller schrieb: > Hab ich - > bis jetzt - noch keine Probleme damit gehabt, ist aber zugegebenermaßen > vermutlich relativ dünnes Eis.. Wieso? Das ist auch für MC's mit Interruptcontroller und ISR-Hirarchie eine sehr bewährte Strategie. Oliver
Oliver schrieb: > Thomas Bergmüller schrieb: >> Hab ich - >> bis jetzt - noch keine Probleme damit gehabt, ist aber zugegebenermaßen >> vermutlich relativ dünnes Eis.. > > Wieso? Das ist auch für MC's mit Interruptcontroller und ISR-Hirarchie > eine sehr bewährte Strategie. Aber nur, wenn man acht gibt. Es ist wichtig, dass man Dinge wie LCD oder UART als 'shared Resource' ansieht und wenn man das in einem Interrupt verwenden will, darauf achtet sich keine Race Conditions einzuhandeln. Letzten Endes geht es immer um die Fragestellung: Was ist, wenn in der Ausgaberoutine an beliebiger Stelle ein Interrupt zuschlägt, der seinerseits die Ausgaberoutine benutzen will. Und das 'an beliebiger Stelle' muss man wörtlich nehmen! AUch muss man sich überlegen, dass ein Ausgabegerät im Regelfall so etwas wie einen Cursor hat, den man ebenfalls als Shared Resource ansehen muss. Es ist nicht akzeptabel, wenn eine einzeln ISR-Ausgabe dazu führt, dass ein anderer Text mitten drinn unterbrochen wird und an einer ganz anderen Stelle fertig geschrieben wird. ALles in allem ist das Thema nicht so einfach wie es zunächst scheint.
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.