Hallo,
ich habe ein Projekt mit einem ATMega328P. Das Problem ist, sobald ich
den RX-Interrupt aktiviere und Daten sende, bzw. eher welche empfange,
stürzt der Mikrocontroller ab.
Weiß jmd. was das ist?!
1
UBRR0H=(uint8_t)(UBRR_VAL>>8);
2
UBRR0L=(uint8_t)(UBRR_VAL);
3
// Enable receiver and transmitter; enable RX interrupt
Ich habe den Fehler wohl so halb gefunden. Das Empfangsbit ist permanent
auf 1. Also ich empfange andauernd Daten, obwohl nichts!!! gesendet
wird.
Hat jmd. einen Rat was das sein könnte? Der Chip wird's wohl nicht sein,
oder?!
Mitlesa schrieb:> Marius D. schrieb:>> .... stürzt der Mikrocontroller ab.>> Das ist wie:>> Wenn ich losfahre geht das Auto kaputt.
Ich habe es jetzt. Wenn ich initialisiere ist es ok.
Sende ich dann einmal Daten, hat er permanenten das Bit an, dass Daten
empfangen wurden.
Daher meine Frage: Muss man das vll. manuell zurücksetzen?!
Habe schon mal mit ATMega168 gearbeitet, da war das nicht so. Und ich
dachte das ist der gleiche Chip nur 32kb. Macht das P dort was aus?! Im
Datenblatt habe ich dazu nichts gesehen!
When the Receive Complete Interrupt Enable (RXCIEn) in UCSRnB is set,
the USART Receive Complete
interrupt will be executed as long as the RXCn Flag is set (provided
that global interrupts are enabled). When
interrupt-driven data reception is used, the receive complete routine
must read the received data from UDRn in
order to clear the RXCn Flag, otherwise a new interrupt will occur once
the interrupt routine terminates.
1 zu 1 aus dem Datasheet
Volker schrieb:> When the Receive Complete Interrupt Enable (RXCIEn) in UCSRnB is set,> the USART Receive Complete> interrupt will be executed as long as the RXCn Flag is set (provided> that global interrupts are enabled). When> interrupt-driven data reception is used, the receive complete routine> must read the received data from UDRn in> order to clear the RXCn Flag, otherwise a new interrupt will occur once> the interrupt routine terminates.>> 1 zu 1 aus dem Datasheet
Ja ich habe es getestet, auch vorher schon. Das klappt nicht.
Pollen ist das Programm zu Groß, ich verschlucke die Hälfte sonst.
Ich habe sogar in der ISR nochmal das Datenregister (Empfangsbuffer)
geleert und in UCR0A = 0 gesetzt, also das 7. Bit.
Sobald er in die ISR geht, stürzt er ab. Betreibe ihn übrigends mit 8Mhz
und 3V3.
Hi
Marius D. schrieb:> Ja ich habe es getestet,
Was ist hier 'es'?
Marius D. schrieb:> must read the received data from UDRn in> order to clear the RXCn Flag
Du musst nicht das Bit löschen, Du musst die Daten lesen - laut dem
Auszug.
Aber weder das Eine, noch das Andere ist in Deiner ISR zu finden :)
MfG
Patrick J. schrieb:> Hi>> Marius D. schrieb:>> Ja ich habe es getestet,>> Was ist hier 'es'?>> Marius D. schrieb:>> must read the received data from UDRn in>> order to clear the RXCn Flag>> Du musst nicht das Bit löschen, Du musst die Daten lesen - laut dem> Auszug.>> Aber weder das Eine, noch das Andere ist in Deiner ISR zu finden :)>> MfG
Das mache ich dort. Ich habe keine Ahnung warum das nicht geht.
Das war ja auch nur der Body als Auszug.
Ich kann das Bit löschen, die Daten lesen es geht alles nicht.
Der resettet sobald ich den ISR aktiviert habe (sei()).
Marius D. schrieb:> Das war ja auch nur der Body als Auszug.
Genau das ist das Problem. Du zeigst Auszüge, von denen du meinst, sie
seien relevant und verstümmelst sie auch noch.
Zeig einen kompletten Code, der compilierbar ist und den Fehler bringt.
Alles andere ist stochern im Nebel.
Marius D. schrieb:> Ich habe keine Ahnung warum das nicht geht.
Wir auch nicht ...
> Das war ja auch nur der Body als Auszug.
Und den Rest magst Du uns nicht zeigen?
Marius D. schrieb:> Das klappt nicht.
Doch, das klappt. Sehr gut sogar.
> Pollen ist das Programm zu Groß, ich verschlucke die Hälfte sonst.
??
Wenn Du mehr Daten an Deinen µC verschickst, als dieser verarbeiten
kann, dann ist entweder die Baudrate zu hoch, der Prozessor zu langsam
oder einfach das Programm zu umständlich. Ich tippe auf letzteres.
Gruß
Jobst
Könnte auch ganz banal ein Speicherüberlauf sein.
Aber was soll die Raterei? Du solltest schon das ganze Programm zeigen.
Nicht dass am Ende noch eine Beschwerde kommt, wie würden hier nur alle
dummes Zeug von uns geben anstatt effektiv zu helfen.
Hi
Also jetzt hör doch Mal auf, Dich zu beschweren gg
@TO
Zeig doch bitte die ganze ISR. (oder sogar das Programm ... vll.
verstellst Du auch andere ISR)
Benutzt Du sei in der ISR? Dann könnte Das schon der springende Punkt
sein, daß die ISR direkt erneut aufgerufen wird, da Sie noch nicht
beendet wurde und ab jetzt wieder Interrupts zugelassen werden - und auf
zur nächsten Runde, bis das nächste sei die Nächste einläutet.
Reine Theorie, man bekommt ja keine Informationen hier ...
MfG
> Wenn Du mehr Daten an Deinen µC verschickst, als dieser verarbeiten> kann, dann ist entweder die Baudrate zu hoch, der Prozessor zu langsam> oder einfach das Programm zu umständlich. Ich tippe auf letzteres.>>> Gruß>> Jobst
Da tippst du leider falsch. Das Programm ist nicht umständlich. Das ist
sogar sehr optimiert und läuft tlws (was die WLAN Sachen angeht) auf den
XMEGA einwandfrei.
Hier habe ich nen Mega genommen, da die sehr kleinen XMega (Xmega32e5)
einfach zu teuer sind. Und für die großen die dann billiger sind
(Xmega32a4) ist nicht genug Platz und wäre auch Verschwendung da nur ein
paar Pinne gebraucht werden.
In der ISR habe ich rein gar nichts gemacht. Ich speichere dort das Byte
in ein Array wie schon beschreiben:
1
ISR(USART0_RXC_vect)
2
{
3
buf[i++]=UDR0;
4
5
if(i>250)i=0;
6
}
Die init habt ihr ja, was ist noch relevant?
Ich denke mal so, wenn ich ein Programm habe, was die Sachen NUR drin
hat (init vom ISR und die ISR, eine while die leer ist) und das hatte
ich testweise drauf gespielt dann frage ich mich was abgeht.
Pollen geht auch. Ich habe testweise jetzt mal so in regl. Abständen
eine Abfrage eingebaut die dann zur Get_Uart_Data fkt springt. Das geht
so, toll finde ich das jedoch nicht.
Achso: Ich habe sogar mal ISR_BLOCK getestet, auch ohne Erfolg.
Ich habe so das leichte Gefühl, das der µC vll. ne Macke hat.
Baud ist 56000 und Watchdog ist mit 2sek. aktiv.
Marius D. schrieb:> Achso: Ich habe sogar mal ISR_BLOCK getestet, auch ohne Erfolg.
Das verstehe ich nicht, ISR_BLOCK geht doch immer.
Probiere doch mal die Option DISABLE_ERROR. Dann müßte alles fehlerfrei
laufen.
Marius D. schrieb:> Da tippst du leider falsch.
Ich denke immernoch, dass ich richtig liege.
Marius D. schrieb:> In der ISR habe ich rein gar nichts gemacht. Ich speichere dort das Byte> in ein Array wie schon beschreiben:
Und Du meinst, dass Du den Quellcode noch immer vor uns verheimlichen
möchtest, wir Dir aber sagen sollen, wo der Fehler steckt?
Okay, Du schreibst in der ISR Daten in ein Array. Sonst wird damit
natürlich nichts gemacht.
Marius D. schrieb:> Ich habe so das leichte Gefühl, das der µC vll. ne Macke hat.
Wahrscheinlich ehr nicht ...
Gruß
Jobst
Marius D. schrieb:> ISR(USART0_RXC_vect)
Liegt im Widerspruch zu:
Marius D. schrieb:> ich habe ein Projekt mit einem ATMega328P
Der ATmega162 hat einen USART0_RXC_vect
Beim ATMega328P heißt das Ding: USART_RX_vect
Jobst M. schrieb:> Wahrscheinlich ehr nicht ...
Sehe ich auch so!
Ich glaube dass der Fehler auf dem OSI-Layer 8 zu suchen ist.
>Pollen geht auch. Ich habe testweise jetzt mal so in regl. Abständen>eine Abfrage eingebaut die dann zur Get_Uart_Data fkt springt. Das geht>so, toll finde ich das jedoch nicht.
Also stimmt etwas mit der ISR nicht.
Vielleicht ein falscher ISR-Vektor?
Übersetzt du deinen Code auch wirklich für den 328P?
Volker schrieb:>>Pollen geht auch. Ich habe testweise jetzt mal so in regl. Abständen>>eine Abfrage eingebaut die dann zur Get_Uart_Data fkt springt. Das geht>>so, toll finde ich das jedoch nicht.>> Also stimmt etwas mit der ISR nicht.> Vielleicht ein falscher ISR-Vektor?>> Übersetzt du deinen Code auch wirklich für den 328P?
Ja, ist wirklich für den 328P.
Jobst M. schrieb:> Marius D. schrieb:>> Da tippst du leider falsch.>> Ich denke immernoch, dass ich richtig liege.
Ok. Wie du willst. Ich weiß es besser.
> Marius D. schrieb:>> In der ISR habe ich rein gar nichts gemacht. Ich speichere dort das Byte>> in ein Array wie schon beschreiben:>> Und Du meinst, dass Du den Quellcode noch immer vor uns verheimlichen> möchtest, wir Dir aber sagen sollen, wo der Fehler steckt?> Okay, Du schreibst in der ISR Daten in ein Array. Sonst wird damit> natürlich nichts gemacht.
Klar. Aber da das nicht funktioniert hat, habe ich das Testprogramm wie
beschreiben drauf gemacht, um zu gucken ob es vll. an meinem vom XMega
importiertem Code für WLAN liegt. Testprogramm macht die gleichen Faxen.
> Marius D. schrieb:>> Ich habe so das leichte Gefühl, das der µC vll. ne Macke hat.>> Wahrscheinlich ehr nicht ...
Hoffe ich auch mal. Waren 10x aus China. Die anderen teste ich, sobald
die Sache läuft, dann baue ich die anderen Teile zusammen.
>> Gruß>> Jobst
Marius D. schrieb:> Ja, ist wirklich für den 328P.
Meine Arduino IDE sagt dazu:
1
In function 'USART0_RXC_vect':
2
3
E:\Daten\Arduino\Forum\UART328\UART328.ino:2:1: warning: 'USART0_RXC_vect' appears to be a misspelled signal handler, missing __vector prefix [-Wmisspelled-isr]
4
5
ISR(USART0_RXC_vect)
Dein Compiler sagt das gleiche, du muss ihm nur mal zuhören!
Arduino F. schrieb:> E:\Daten\Arduino\Forum\UART328\UART328.ino:2:1: warning:
Du musst ein blutiger Anfänger sein. Der Könner schaltet alle Warnungen
ab.
(SCNR)
Georg G. schrieb:> Du musst ein blutiger Anfänger sein.
Ja, so in etwa...
Georg G. schrieb:> Der Könner schaltet alle Warnungen ab.
Ich bin zu ehrgeizig/stolz, um mit solchen Fragen hier im Forum
aufzuschlagen.
Wenn die Warnungen mir dabei helfen, dann schalte ich sie ein.
Und wenn das nur was für Weicheier ist, dann bin ich eben ein Weichei.
Arduino F. schrieb:> Marius D. schrieb:>> ISR(USART0_RXC_vect)>> Liegt im Widerspruch zu:>> Marius D. schrieb:>> ich habe ein Projekt mit einem ATMega328P>> Der ATmega162 hat einen USART0_RXC_vect> Beim ATMega328P heißt das Ding: USART_RX_vect>> Jobst M. schrieb:>> Wahrscheinlich ehr nicht ...> Sehe ich auch so!> Ich glaube dass der Fehler auf dem OSI-Layer 8 zu suchen ist.
Jo das war es. Der Vector ohne C und nun geht's.
Habe ich mich verlesen im Datenblatt.
Volker schrieb:> @Marius:>> Wie stellst du eigentlich fest ob der MC noch läuft bzw "abgestürzt"> ist?
Ich habe nach der uart-init (also vor der while(1) ein "START" gesendet
und dann geguckt.
Thread beobachten
Seitenaufteilung abschalten