Hallo, ich habe folgendes Problem, an dem ich nun schon länger verzweifele. Ich habe eine Hardware, in der ein RN4678 BT-Modul verbaut ist. Mit der Hardware kann ich Daten von einer SD-Karte über wahlweise USB (FTDI Virtueller COM-Port) oder Bluetooth (SPP) senden. Nun habe ich das Problem, dass es beim Senden über BT hin und wieder zu Datenfehlern kommt. USB funktionert problemlos. Folgendens habe ich festgestellt: Die Anzal der empfangenen Bytes entspricht der Anzahl der gesendeten Bytes. Mittendrin werden irgendwann Bytes vertauscht. Wenn ich die Verbindung mit hterm als SerialPort öffene, dann kann ich die Flow Control Leitung des BT-Moduls nicht manuell über das Terminalprogramm setzen. Bei der USB Verbindung geht das. Wenn ich da RTS manuell wegschalte, hört das Gerät auf zusenden. RTS/CTS Flow Control sind per default im BT-Modul aktiviert. Nochwas ist mir aufgefallen. Wenn ich nach dem Senden der ersten Bytes kurz warte und dann weitersende, passieren die Übertragungsfehler eher selten. Ich hab das Gefühl, dass das Modul erst mal irgendwie aufwachen muss, obwohl die Verbindung permanent besteht. Danke und Viele Grüße, Alex
Alexander H. schrieb: > Danke und Viele Grüße Danke wofür? Ich finde kein Anliegen von dir, nur eine (kleine, vage) Berichterstattung von dem was du hast und was du tust. Üblicherweise stellen hier Thread-Ersteller eine Frage. Vermauschelte Dinge zwischen den Zeilen zu lesen führt oft ins Kommunikations-Chaos.
jo mei schrieb: > Alexander H. schrieb: >> Danke und Viele Grüße > > Danke wofür? Ich finde kein Anliegen von dir, nur eine (kleine, > vage) Berichterstattung von dem was du hast und was du tust. > > Üblicherweise stellen hier Thread-Ersteller eine Frage. > Vermauschelte Dinge zwischen den Zeilen zu lesen führt oft > ins Kommunikations-Chaos. Da hast du natürlich Recht. Meine Frage im allgemeinen ist, wo das Problem liegen kann und ob jemand mit diesem oder einem ähnlichen Modul Erfahrung hat, konkreter vielleicht: 1. Kann das beobachtete Verhalten durch eine nicht funktionierende Flusssteuerung entstehen? Ich würde ja eher vermuten, dass da Bytes "verschwinden" und nicht vertauscht werden. 2. Funktioniert der COM-Port bei SPP analog zu einem virtuellen COM-Port über USB? Wie gesagt, ich kann die Steuerleitung nicht manuell setzten, so wie das bei dem VCP geht. Weshalb ich vermute, dass die Flusskontrolle nicht geht.
Wie hoch ist die Baud Rate auf dem UART? Ich frage das weil bei hohen Baudraten auch die FTDI Teile >1 Byte brauchen um auf das Flussteuerungs Signal zu reagieren. Da können dann auch mal Daten verloren gehen. Ansonsten halte halt mal einen LA an den UART mit ran. Am Besten fährt man mit CRC auf der Protokoll Schicht. Auf der BT Seite gibt es keine "Flußkontroll" Signale, aber IIRC war die Auslieferung der Daten garantiert - d.h. aber leider auch dass die Datenrate bei Funkstörungen einbricht.
Alexander H. schrieb: > Ich habe eine Hardware, in der ein RN4678 BT-Modul verbaut ist. Klemm H-Term direkt an den TTL Uart des Moduls. Noch weiß Du nicht ob nicht die ominöse HW diese Vertauschung durchführt weil unsauber programmiert. Wenn Du das weißt, dann kanst Du weitersuchen.
Jim M. schrieb: > Wie hoch ist die Baud Rate auf dem UART? 115200 Baud zuwischen Modul und uC, ich habe auch nichts weiter umkonfiguriert, nur den frindliy user name geändert und BLE abgeschaltet (nur noch Classic) > Auf der BT Seite gibt es keine "Flußkontroll" Signale, aber IIRC war die > Auslieferung der Daten garantiert - d.h. aber leider auch dass die > Datenrate bei Funkstörungen einbricht. Aber das Modul unterstützt RTS/CTS und das ist auch per default aktiv. Wenn es die Daten nicht los wird, würde ich erwarten, dass da was signalisert wird. Wenn ich auf der PC-Seite per auf das Modul per COM-Port zugreife (SSP), da gibt's da auch RTS/CTS. Nur scheint das irgendwie anders zu funktioniern als bei VCP. Ich habe auch festgestellt, dass die Kommunikation prizipiell funktioniert, wenn ich beim Terminal eine geringere Baudrate einstelle als 115200. Da scheint es also Unterschiede zu VCP zu geben. > Klemm H-Term direkt an den TTL Uart des Moduls. Das geht leider nicht, weil da der Controller angeschlossen ist.
Alexander H. schrieb: >> Klemm H-Term direkt an den TTL Uart des Moduls. > Das geht leider nicht, weil da der Controller angeschlossen ist. Wenn Du keine Verbindungen auftrennen willst, hängt Dich mit drin, les mit was empfangen wird und vergleiche.
Hi, ich wollte nur kurz mitteilen, dass ich den Fehler gefunden habe. Ich habe festgestellt, dass wenn das BT-Modul zwar verbunden ist, aber eine Weile keine Daten gesendet hat, etwas Zeit braucht, bis es losgeht. Meine UART-Ausgabe ist gepuffert und ich habe nur beim Beschreiben des Puffers auf die RTS-Leitung gehört, nicht aber im Interrupt, der die Daten aus dem Puffer in die UART schreibt. Deshalb habe ich immer noch den Puffer leer geschrieben und so das Problem verursacht. Darüber hinaus war mir die Funktionsweise des SSP COM-Ports nicht ganz klar. Ich hatte angenommen, dass dieser analog zu einem virtuellen COM-Port via USB funktioniert. Macht er aber nicht, wie ich jetzt weiß. Danke für eure Hilfe. Grüße, Alex
:
Bearbeitet durch User
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.