Hallo Leute, Ich verwende einen 89LPC936 von NXP. Die UART arbeitet als reiner Receiver. Die seriellen Daten, die empfangen möchte, werden mit 11 Null-Bits eigeleitet. Beim Empfang dieser 11 Null-Bits setzt die UART Hardware ein BREAK DETECT Flag. Das funktioniert auch soweit. Jetzt habe habe ich das Problem das in dem Datanblatt steht das die UART nach einem ekrannten BREAK DETECT in einen IDLE Modus geht und erst nach einem empfangenen Stop-Bit wieder aufwacht. Was auch immer Idle Modus genau bedeutet. Da nach den 11 Null-Bits direkt ein Datenbyte kommt, es handelt sich hier um das DMX Protokoll, verpasse ich dieses da die UART ja noch im IDLE Modus ist. So ganz verstehe ich das alles noch nicht. Hat jemand Erfahrungen mit dem diesem BREAK DETECT Modus gemacht und kann mir ein paar Tipps geben? Ich wäre sehr dankbar.
Anderas Baehne wrote: > Da nach den 11 Null-Bits direkt ein Datenbyte kommt, es > handelt sich hier um das DMX Protokoll, verpasse ich dieses da die UART > ja noch im IDLE Modus ist. Nein, das geht nicht. Du mußt nach einem Break erstmal ein Stop-Bit senden (d.h. abwarten), sonst kann der Empfänger ja nicht das Startbit erkennen. Er braucht die 1-0-Flanke. Peter
Na klar, http://www.nxp.com/search/?query=UM10116 Kapitel 11.9 Break detect Ich arbeite im Mouds UART Modus 3
Hallo Peter, ich habe es vermutet. :-( Glücklicher Weise ist das erste Byte immer Null da es bis jetzt von der meisten DMX Hardware nicht benutzt wird. Merkwürdiger weise scheint mein Programm nicht in die Break Detect ISR zu laufen. Im Keil Debugger funktioniert es wenn ich im UART Fenster das BR Flag setze. Weißt Du wann genau die Hardware die BR ISR anspringt. Müßte doch eigentlich direkt nach dem Setzen des BR Flags sein.
Kurzer Kommentar zum Thema Idle mode. Idle mode betrifft in erster Linie die CPU, nicht die Peripherie. Im Idle Mode wird die CPU nicht mit einem Takt versorgt -> Strom sparen. Der UART wird allerdings getaktet und kann empfangen, doch das Problem liegt wohl daran, dass der Uart gar nicht weiss, dass die Daten anfangen. Wie bereits gesagt, das kommt also das Break, dann muss der UART zuerst wieder erkennen, dass es sich nicht um einen Kurzschluss nach Masse handelt, also muessen Stopbits (high) kommen. Wenn jetzt wieder ein Startbit kommt, dann weiss der UART, dass es Daten sind. Ich kenne das DMX Protokoll nicht aber es hoiert sich so an, als ob ein regulaerer UART nicht verwenet werden kann. Wenn ich Deinen Text richtig verstehe, dann ist die Startbedingung und das erste Datenbyte ohen Paus dazwischen aneinender gekoppelt. Das ist nicht fuer einen UART, da muss wahrscheinlich eine Software Loesung ran!? Kann es sein, dass nach dem Break eine "ganz normale" UART Kommunikation eingeleitet wird? Dann waere jedenfalls ein Stopbit und ein neues Startbit dazwischen und alles sollte ohen Probleme laufen. Der UART wuerde das Byte empfangen und die CPU nach dem Empfang aufwecken. Robert
Hallo Robert, vielen Dank für deine Erleuterungen. Wenn es so ist das die UART nach dem Break Detect lediglich auf einen High-Pegel über eine gewisse Zeit wartet dann sollte es mit dieser UART gehen. Nach der Startbedingung, also den sogenannten 11 Null Bits im DMX Protokoll, folgt wenigstens für 8us ein High. Bei meiner DMX Quelle (gekauftes Pult) sind es sogar 100us. Es vergeht also quasi eine Ewigkeit zwischen Startbedingung und dem ertsen Datenbyte. Eine gute Darstellung des Protokolls gibt es bei: www.soundlight.de/techtips/dmx512/dmx512.htm weiter unten auf der Seite. Ich sollte also mal im Code und im Controller Datenblatt schauen ob ich einen Idle Modus durch setzten von Flags im Power Con Register verhindern kann. Außerdem bin ich jetzt zuversichtlich noch mal in meinem Code nach eventuellen Fehlern zu suchen. Mir war nicht bewusst wofür dieser Break Detect und der Idle Mode sein sollten. Manchal versteht man die Dinge besser wenn man die Geschichte kennt. Danke
Anderas Baehne wrote: > wartet dann sollte es mit dieser UART gehen. Nach der Startbedingung, > also den sogenannten 11 Null Bits im DMX Protokoll, folgt wenigstens für > 8us ein High. Sag ich doch: 8µs = eine Bitzeit High. Damit ist jede UART zufrieden. Peter
Anderas Baehne wrote: > Ich sollte also mal im Code und im Controller Datenblatt schauen ob ich > einen Idle Modus durch setzten von Flags im Power Con Register > verhindern kann. Nur um klarzustellen, daß sich der idle-state der UART nicht auf einen idle Mode der CPU bezieht hier nochmal der Auszug aus dem Datenblatt. "Once a break condition has been detected, the UART will go into an idle state and remain in this idle state until a stop bit has been received." Das bedeutet nur, daß der UART wartet bis er ein Stopbit empfängt, bevor er wieder normal arbeitet, so wie es auch gesagt wurde. Aber die CPU bleibt weiterhin im normalen Betriebsmode und geht nicht in einen idle Mode. Ciao, Rainer
Hallo Rainer, also doch. Aber sobald die Rx Leitung wieder ein High-Pegel führt sollte die UART wieder aufwachen. Nach dem Break-Signal kommt für mind. 8us ein High-Pegel. Ich denke das reicht der UART.
@ Andreas und Rainer, manchmal wuerde es schon helfen die Manuals zu lesen bei denen man selbst mitgeschrieben hat :-( Natuerlich hat Rainer recht, dieser Idle Mode bezieht sich tatsaechlich auf den UART. Es bedeutet nicht anderes als dass der UART nicht die ganze Zeit weitermacht und "Null-Bytes" empfaengt, sondern einfach wartet bis die Leitung wieder "high" wird. Es scheint wir kommen alle zum gleichen Schluss, es sollte ohne Probleme moeglich sein den UART zu verwenden. Robert
@Robert ich verstehe, dass verhindert also das im Fehlerfall der Leitung die UART permanent Interrupts erzeugt und die CPU beschäftigt. Ich bin jetzt wieder voller Hoffnung und freue mich aufs nächste Wochenende :-). Vielen Dank an alle und möge dieser Artikel auch noch anderen nützen. Andreas
Bitte 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.