Bluetooth-Modul Microchip RN4678, Flow Control funktioniert nicht

[Alexander H. (ill_son)]

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

[jo mei (Gast)]

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.

[Alexander H. (ill_son)]

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.

[Jim M. (turboj)]

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.

[Max M. (Gast)]

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.

[Alexander H. (ill_son)]

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.

[Max M. (Gast)]

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.

[Alexander H. (ill_son)]

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