Hallo zusammen! Um eine eine "größere" Menge an Daten effizient zu verarbeiten verwende ich einen FIFO von Roboternetz: http://www.rn-wissen.de/index.php/FIFO_mit_avr-gcc Im Prinzip Funktioniert alles. Allerdings bleiben manchmal Daten im FIFO hängen. Sie kommen erst raus, wenn ich neue Daten nachschiebe. Wahrscheinlich weil ich die Interrupts nicht abschalte während der schreib- oder Lesepointer neu geschrieben wird. Also habe ich versucht die Interrupts abzuschalten. Das führt aber anscheinend zu spurious Interrupts die für einen reset des µC sorgen. http://www.embeddedrelated.com/usenet/embedded/show/92645-1.php Als Lösung des Problems soll man vor dem abschalten noch vorhandene Interruptanforderungen löschen. In dem Fall verliere ich aber die Daten im UART Hardware FIFO? Wie kann man das Problem lösen? Es muss doch möglich sein schon empfangene Daten zu verarbeiten während im Interrupt neue in den FIFO geschoben werden. Mfg, Kurt
Spurious Interrupts sind bei den LPC2000 nicht ungewöhnlich und kein Drama. Zum Reset führen sie, wenn man keinen Default-Handler für nichtvektorierte Interrupts definiert. Der ist bei den LPC2000 Pflicht, auch wenn alle verwendeten Interrupts vektoriert sind. > Als Lösung des Problems soll man vor dem abschalten noch vorhandene > Interruptanforderungen löschen. Sagt wer? Allerdings wird zu diesen spurious Interrupts ziemlich viel konfuses Zeug verbreitet, auch NXP ist sich da nicht zu schade für.
Ok. Das werde ich mir mal ansehen. Dabei fällt mir auf dass im Demoprogramm natürlich die Intialisierung des VIC fehlt. A. K. schrieb: >> Als Lösung des Problems soll man vor dem abschalten noch vorhandene >> Interruptanforderungen löschen. > > Sagt wer? Die Beiträge bei embeddedrelated.
Den Thread werde ich mir jetzt auch noch durchlesen. Aber schon jetzt ein RIESENGROßES DANKESCHÖN U0IER &= ~1; VICIntEnClr=(1<<VIC_UART0); bei fifo_put und fifo_get und VICDefVectAddr = (unsigned int)U0_ISR; im Init scheinen das Problem gelöst zu haben. Bei über 20 Programmdurchläufen kein einziger Reset oder verrschlucken von Daten. Mfg, Kurt
Kurt Bohnen schrieb: > U0IER &= ~1; > VICIntEnClr=(1<<VIC_UART0); Gürtel-und-Hosenträger Prinzip? Die zweite Zeile tät reichen. Ausser dir kommt eine race condition dazwischen, wenn der Interrupt schon ansteht während er damit abgeschaltet wird und dein Default-Handler, der ja bei dir mit dem UART-Handler identisch ist, kommt grad noch zum unpassendsten Moment zum Zuge. Was übrigens ein Grund wäre, den Default-Handler eben nicht mit dem UART-Handler zu verbinden. Ich ziehe es allerdings ohnehin vor, bei solchem Kleinkram den IRQ vom Core abzuschalten, statt den VIC oder den Request der Peripherie. Da bleiben race conditions aussen vor. Dann sind zwar auch andere IRQ betroffen, aber bei nur wenigen Takten ist das meist egal.
A. K. schrieb: > Gürtel-und-Hosenträger Prinzip? Die zweite Zeile tät reichen. Stimmt natürlich. Ist geändert. A. K. schrieb: > Was übrigens ein > Grund wäre, den Default-Handler eben nicht mit dem UART-Handler zu > verbinden. Ist auch geändert.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.