FT232RL funktioniert nur halb unter Linux (Ubuntu)

[R. B. (britzi)]

Hallo zusammen,

ich habe leider ein riesen Problem mit einem FT232RL.

Der FT232 wird korrekt erkannt und ttyUSB0 zugeordnet.
Wenn ich nun mit einem Terminalprogramm wie z.B. CuteCom darauf 
zugreifen möchte, funktioniert alles super.

Allerdings benötige ich unbedingt Zugriff durch ein C++-Programm, 
welches die Bibliothek QtSerialPort nutzt. Das Programm ansich habe ich 
auch schon mit einem BTM-222 getestet, welches sich als rfcomm0 
einbinden lässt. Hier funktioniert alles super.

Aber mit dem FT232RL öffnet sich nur ein leeres Konsolenfenster und die 
Anwendung bleibt hängen. Ich bekomme keine Fehlermeldungen.

Ich tippe auf irgend ein Rechte- oder Initialisierungsproblem.
Googlen hat leider bisher nichts geholfen.

Ich hoffe ihr könnt mir helfen.

Vielen Dank :-)

Das hier gibt dmesg aus:

[17118.389518] usb 2-2.2: new full-speed USB device number 7 using uhci_hcd
[17118.890094] usb 2-2.2: New USB device found, idVendor=0403, idProduct=6001
[17118.890098] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[17118.890099] usb 2-2.2: Product: FT232R USB UART
[17118.890100] usb 2-2.2: Manufacturer: FTDI
[17118.890101] usb 2-2.2: SerialNumber: A602KBZE
[17118.937071] ftdi_sio 2-2.2:1.0: FTDI USB Serial Device converter detected
[17118.937119] usb 2-2.2: Detected FT232RL
[17118.937121] usb 2-2.2: Number of endpoints 2
[17118.937123] usb 2-2.2: Endpoint 1 MaxPacketSize 64
[17118.937123] usb 2-2.2: Endpoint 2 MaxPacketSize 64
[17118.937124] usb 2-2.2: Setting MaxPacketSize 64
[17118.968383] usb 2-2.2: FTDI USB Serial Device converter now attached to ttyUSB0

Und so wird es in Cpp initialisiert:

serial.setPortName("/dev/ttyUSB0");  // oder /dev/rfcomm0 für BTM-222
serial.open(QIODevice::WriteOnly); //ReadWrite
serial.setBaudRate(QSerialPort::Baud19200);
serial.setDataBits(QSerialPort::Data8);
serial.setParity(QSerialPort::NoParity);
serial.setStopBits(QSerialPort::OneStop);
serial.setFlowControl(QSerialPort::NoFlowControl);

[öh? (Gast)]

R. B. schrieb:
> serial.open(QIODevice::WriteOnly); //ReadWrite

Öh?

[R. B. (britzi)]

öh? schrieb:
> R. B. schrieb:
>> serial.open(QIODevice::WriteOnly); //ReadWrite
>
> Öh?

Ist doof geschrieben, sorry ;)
Das "//ReadWrite" ist nur ein Kommentar, falls ich mal ebenfalls 
lesenden Zugriff brauche.


Mit genau diesen Einstellungen funktioniert es ja mit einem BTM-222.

Nur mit dem RT232RL geht nix :-(

[Peter II (Gast)]

R. B. schrieb:
> Anwendung bleibt hängen

und wo bleibt sie hängen?

[R. B. (britzi)]

Peter II schrieb:
> R. B. schrieb:
>> Anwendung bleibt hängen
>
> und wo bleibt sie hängen?

Das Programm bleibt direkt beim Anfang, der Initialisierung der 
seriellen Schnittstelle hängen.

Wie ich genaueres sichtbar machen kann, weiß ich leider nicht.


Ich denke, dass das Programm beim Zugriff auf ttyUSB0 Probleme hat.

Leider kenne ich mich nicht so gut mit Linux aus und weiß nicht, was für 
Rechte ein Programm braucht, um die Schnittstelle bedienen zu können.

Ich habe den ausführenden Nutzer schon der Gruppe "Dialout" hinzugefügt, 
aber das hat nichts geholfen.

[Peter II (Gast)]

R. B. schrieb:
> Wie ich genaueres sichtbar machen kann, weiß ich leider nicht.

dann debugge es oder schreibt ein paar prints rein.

es hängt hilft nicht gerade bei der Fehlersuche.

[g457 (Gast)]

> Wie ich genaueres sichtbar machen kann, weiß ich leider nicht.

printf? fprintf? cout? cerr? $debugger?

> Ich habe den ausführenden Nutzer schon der Gruppe "Dialout" hinzugefügt,
> aber das hat nichts geholfen.

Wenns daran läg bekämst Du entsprechende Fehler (die Du ja hoffentlich 
irgendwo abfängst).

[R. B. (britzi)]

Peter II schrieb:
> R. B. schrieb:
>> Wie ich genaueres sichtbar machen kann, weiß ich leider nicht.
>
> dann debugge es oder schreibt ein paar prints rein.
>
> es hängt hilft nicht gerade bei der Fehlersuche.

Sorry, bin schon etwas müde ;-)
Habs gerade getestet.
Es hängt beim öffnen der Schnittstelle 
(serial.open(QIODevice::WriteOnly);)

Das bedeutet ein Terminalprogramm kann die Schnittstelle öffnen, mein 
C++-Programm allerdings bekommt keinen Zugriff. :-(

[g457 (Gast)]

> Das bedeutet ein Terminalprogramm kann die Schnittstelle öffnen, mein
> C++-Programm allerdings bekommt keinen Zugriff.

Hängt da noch ein altes Lockfile rum? lass mal strace drauf los.

[R. B. (britzi)]

g457 schrieb:
>> Das bedeutet ein Terminalprogramm kann die Schnittstelle öffnen, mein
>> C++-Programm allerdings bekommt keinen Zugriff.
>
> Hängt da noch ein altes Lockfile rum? lass mal strace drauf los.

Das kannte ich noch gar nicht.

Ich habe jetzt mal nur den Teil kopiert, der für mich interessant zu 
sein scheint. Der Teil wiederholt sich vielfach hintereinander.
Hier das Ergebnis:

access("/var/lock", R_OK)               = 0
access("/var/lock", W_OK)               = 0
open("/dev/ttyUSB0", O_WRONLY|O_NOCTTY|O_NONBLOCK) = 16
uname({sys="Linux", node="ubuntu", ...}) = 0
open("/var/lock/LCK..ttyUSB0", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = -1 EEXIST (File exists)
open("/var/lock/LCK..ttyUSB0", O_RDONLY|O_CLOEXEC) = 17
fcntl(17, F_SETFD, FD_CLOEXEC)          = 0
fstat(17, {st_mode=S_IFREG|0644, st_size=13, ...}) = 0
fstat(17, {st_mode=S_IFREG|0644, st_size=13, ...}) = 0
read(17, "4516\n\nubuntu\n", 16384)     = 13
read(17, "", 16371)                     = 0
brk(0x1790000)                          = 0x1790000
close(17)                               = 0
nanosleep({0, 100000000}, 0x7fff56dce170) = 0

Ich muss gestehen, dass ich hier nichts draus lesen kann.

[Sven B. (scummos)]

open("/var/lock/LCK..ttyUSB0", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) 
= -1 EEXIST (File exists)

Das sieht doch interessant aus ;)

[g457 (Gast)]

> open("/var/lock/LCK..ttyUSB0", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644)
> = -1 EEXIST (File exists)

..das Lockfile gibts schon

> read(17, "4516\n\nubuntu\n", 16384)     = 13

..geraten: es gibt einen Prozess mit pid 4516, dem das Lockfile gehört.

[g457 (Gast)]

Nachtrag: schau mal, obs besagten Prozess gibt, wenn nicht (oder wenns 
unwahrscheinlich ist, dass jener die uart belegt) dann töte mal das 
Lockfile (braucht vmtl. root-Rechte).

[Sven B. (scummos)]

g457 schrieb:
>> read(17, "4516\n\nubuntu\n", 16384)     = 13
>
> ..geraten: es gibt einen Prozess mit pid 4516, dem das Lockfile gehört.

Stimmt, gut geraten, die zweite Zeile ist bestimmt der Hostname auf dem 
der Prozess läuft.

[R. B. (britzi)]

Ihr seid meine absoluten Retter :-)

Vielen vielen Dank!

Den Prozess gab es nicht.

Aber das Löschen des Lockfiles hat den Erfolg gebracht :-)

Wie entsteht denn so ein Lockfile und ist dass normal, dass sowas 
passiert?



Vielen Dank nochmal :-)

[g457 (Gast)]

> Wie entsteht denn so ein Lockfile [..]

Man legt es (absichtlich) an - hier macht das Qt :-)

> [..] und ist dass normal, dass sowas passiert?

Das Lockfile als solches: ja, ein 'stale lockfile' dagegen sollte man um 
jeden Preis vermeiden (oder (als Programm) selbst adäquat aufräumen 
können, stattdessen einen Deadlock zu produzieren ist per se ein no-go), 
weil sonst genau obiges passiert :-)

[R. B. (britzi)]

Danke nochmals :-)

Ich habe wieder viel gelernt.

[Sven B. (scummos)]

g457 schrieb:
> Das Lockfile als solches: ja, ein 'stale lockfile' dagegen sollte man um
> jeden Preis vermeiden (oder (als Programm) selbst adäquat aufräumen
> können, stattdessen einen Deadlock zu produzieren ist per se ein no-go),
> weil sonst genau obiges passiert :-)

Genau, und normalerweise vermeidet man das indem man mal schaut ob's den 
Prozess aus dem Lockfile noch gibt -- was hier aber wohl nicht passiert. 
Das wäre vielleicht sogar einen Bug Report gegen QtSerial wert?