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:
1
[17118.389518] usb 2-2.2: new full-speed USB device number 7 using uhci_hcd
2
[17118.890094] usb 2-2.2: New USB device found, idVendor=0403, idProduct=6001
3
[17118.890098] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
4
[17118.890099] usb 2-2.2: Product: FT232R USB UART
5
[17118.890100] usb 2-2.2: Manufacturer: FTDI
6
[17118.890101] usb 2-2.2: SerialNumber: A602KBZE
7
[17118.937071] ftdi_sio 2-2.2:1.0: FTDI USB Serial Device converter detected
8
[17118.937119] usb 2-2.2: Detected FT232RL
9
[17118.937121] usb 2-2.2: Number of endpoints 2
10
[17118.937123] usb 2-2.2: Endpoint 1 MaxPacketSize 64
11
[17118.937123] usb 2-2.2: Endpoint 2 MaxPacketSize 64
12
[17118.937124] usb 2-2.2: Setting MaxPacketSize 64
13
[17118.968383] usb 2-2.2: FTDI USB Serial Device converter now attached to ttyUSB0
Und so wird es in Cpp initialisiert:
1
serial.setPortName("/dev/ttyUSB0"); // oder /dev/rfcomm0 für BTM-222
ö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 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.
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.
> 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).
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. :-(
> 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.
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:
> 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.
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).
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.
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 :-)
> 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 :-)
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?
