ich wollte per Bluetooth eine virtuell-serielle Verbindung zwischen zwei
Linux-PC aufbauen.
Üblicherweise verwende ich bei wired-seriellen Leitungen die
open()/write() Funktionen. Das stand bei Richard Stevens und das habe
ich immer so gemacht.
Bei rfcomm hat open() nicht funktioniert, zu viele Daten gingen
verloren.
Auf der Console konnte ich mit "echo blabla >/dev/rfcomm0" und "cat
/dev/rfcomm0" sicher kommunizieren, aber da fiel mir schon auf, dass
viele NEwlines reinwanderten.
Ich habe dann das C-Programm für die Kommunikation mit fopen realisiert,
FILE *fh=fopen("/dev/rfcomm0","rb+"); fwrite(buf,1,len,fd);
Die Kommunikationen lief gut, aber CR wurden in NL übersetzt und NL
zunächst verdoppelt, trotz der des Binär-Modus "rb+".
Kennt jemand das Problem und die Lösung?
Muss man das vielleicht bei den Bluez-Einstellungen (hcitools,
hciconfig, rfcomm) machen?
Nachtrag:
http://www.tapr.org/pipermail/aprssig/2011-May/036156.html
verwenden die:
stty -F /dev/rfcomm0 4800 raw
Aber mir ist nicht klar, an welcher Stelle man den Befehl hat.
Vor "rfcomm accept" kennt er das Device "rfcomm0" noch nicht.
Gast
#2900922
Nee, tcflush hatte ich auch schon ausprobiert. Negativ. tcflush ist dazu da, Daten im Buffer sofort rauszuschreiben. Hat aber auf CR/NL Umwandlung keinen Einfluss. stty war ja i.O. Allerdings funktioniert es jetzt immer auch nach Neustart beider Rechner, das System hat sich das irgendwie gemerkt.
Gast
#2901379
"INLCR Translate NL to CR on input." und es ist nicht tcflush, sondern termios(3) und dort genauer tcsetattr und tcgetattr.
> sondern termios(3) und dort genauer tcsetattr und tcgetattr.
Liesst Du eigentlich die Posts von den anderen oder nur die
Überschriften?
Ich hatte doch im ersten Post genau beschrieben, dass ich bei RS232
immer mit open()/read()/write() verwendete (und DAMIT AUCH tcsetattr,
..., da man NUR DAMIT Baudrate, Stoppbits, ... einstellen kann).
tcsetattr-Einstellungen, die mit wired-serial (/dev/ttyUSB0)
funtionieren, funktionieren aber bei Bluetooth Ports NICHT.
Bluetooth comm funktioniert aber super mit fopen/fwrite, aber FILE *
stellt kein tcsetattr zur Verfügung (ausgenommen fileno())
Hi, ist ja schon eine Weil eher, aber vielleicht hilft es jemandem: Ggf. kann man sich mit fileno() zu einem FILE* den low-level-fd holen und darauf dann mit tcgetattr() etc. losgehen.
> Bei rfcomm hat open() nicht funktioniert, zu viele Daten gingen > verloren. Beim Lesen oder beim Schreiben? Beim Schreiben könnte es aufgrund zu kleiner Buffer durchaus sein, dass das write mit weniger Bytes zurückkehrt als als Länge übergeben wurden.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.