ATmega1284p, UART Probleme

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..

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

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)

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?

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.

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.

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..

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.