Hallo Leute, Ich habe eine Frage, seit einiger Zeit quäle ich mich mit einem USART Problem herum. Der wohl allen bekannte Bufferüberlauf hat auch bei mir zugeschlagen. Mein Projekt handelt sich darum, mit einem PIC 18LF873A (Selber Baustein wie 18F873A nur Stromsparender und teurer), ein Funkmodul anzusteuern, und auf einen gewissen String der empfangen werden muss, einen anderen String auszusenden. Leider ist es jetzt so, dass mit den Standart Bibliotheken von meinem CSS Compiler, dieses Problem unlösbar scheint, da der Befehl getc(), irgend einmal zu hängen beginnt, weil der Buffer überläuft. Diesem Problem wollte ich Herr werden, in dem ich die USART selber ansteuere, das habe ich bereits getan, und es läuft super. Bis auf etwas, und zwar wieder dieser lästige Bufferüberlauf. Laut Datenblatt soll man bei einem Überlauf das CREN Bit neu setzen. Das Funktioniert zwar super, nur leider bringt mir das nichts, da der String so nicht mehr ganz empfangen werden kann, da der Buffer während des Empfanges verloren geht, da der String (11 Zeichen lang), wohl die Buffergrösse übersteigt. Kann mir jemand einen Tip geben? Das wäre nett, mein Chef wartet nämlich schon sehnlichst darauf. Mit freundlichen Grüssen pheak
Einen Fehler konnte ich erruieren. Die Funktion "Funkmodulempfangen()", darf nicht vor dem Empfang ausgeführt werden. Dafür habe ich diese jetzt am Ende jeder Sende Aktion ausgeführt. Nun sendet mein PIC auch die Daten, aber leider nur 2 Mal, danach ist der Buffer wieder voll. Ich kann mir das nicht so ganz erklären, und bin auf Hilfe angewiesen. Vielen Dank!
Nutze das main, denn dazu ist es ja da. D.h. ziehe alle zeitraubenden Sachen aus den Interrupts raus und mache sie gemütlich im main. Also die ganzen delays und das Senden im Polling mode. In CPU-Zyklen gerechnet, dauern diese Sachen Jahre. Kein Wunder, wenn die CPU dann andere Sachen nicht mehr schafft. Peter
Habe festgestellt, dass es sich gar nicht um ein Zeitliches Problem handelt, sondern darum, dass ich ein Echo auf der RX Leitung habe. Das heisst, während des sendens, kommt ein Teil wieder auf der RX Leitung zurück, so dass der Interrupt wieder ausgeführt wird. Leider kann ich mir nicht erklären woher dieses Echo stammt. Denn dadurch wird das Senden unterbrochen, und das Funkmodul, da es im Sende Modus ist, kann nichts empfangen. Peter: Danke für die Antwort, leider müssen diese Dinge aber gleich darauf folgend passieren. Das Senden und Empfangen sollte schlussendlich nicht mehr als 10ms beanspruchen. Gruss Adrian
"Leider kann ich mir nicht erklären woher dieses Echo stammt." Das sogenannte Halb-Duplex ist sehr gebräuchlich. Beim 8051 gibt es extra dafür das REN-Bit (receive enable), mit dem kann man dann den Empfang während des Sendens sperren. Peter
Herzlichen Dank! Ich werde mich danach umsehen! Aber etwas scheint mir seltsam, steuere ich den PIC über den Rechner an, funktioniert das Programm einwandfrei, ohne das Echo, schalte ich aber wieder um auf das Funkmodul, so existiert dieses Echo. Das Problem daran ist, dass dieses Echo nicht gesendet werden sollte, sonst wird mein Telegramm verfälscht, und das wäre nicht meine Absicht. Gruss Adrian
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.