Qt: Problem mit readAll

[Olaf (Gast)]

Moin da draussen,

Ich hab vor einiger Zeit mal ein Programm mit Qt geschrieben welches
den USB-Port meines Oszis ausgelesen hat. Der Oszi simuliert im prinzip 
eine
RS232.
Das hat auch mal funktioniert!

Mittlerweile habe ich leider einen neuen, Rechner, eine neue 
Linuxinstallation und wohl auch eine neuere Qt-Version. Aktuell ist es 
5.12.3, es war mal 5.7.

Folgendes passiert:

Ich loesche den Empfangsbuffer:

        serial->clear(QSerialPort::Input);
  serial->flush();

Ich sende dem Oszi die Aufforderung mir seinen ID-String zu schicken:

    sendString(MyString);

Ich warte eine Zeit lang mit waitForReadyRead

Ich lese mit serial->readAll().

Als Antwort bekomme ich das hier:
1`1`HAMEG,HMO2022,014315064,04.531 1`1`1`

Diese 1`, also 0x31 und 0x60 sind zuviel! Die Anzahl der ueberzaehligen 
Zeichen haengt von der Wartezeit ab. Warte ich also zwischen dem Buffer 
loeschen und dem Senden etwas habe ich vor der Antwort mehr Fehlzeichen, 
warte ich danach etwas laenger habe ich dort mehr Fehlzeichen.
Es sieht also so aus als wenn irgendwas den Buffer der virtuellen (USB!) 
seriellen Schnittstelle langsam mit falschen Zeichen füllt.
Hat da jemand eine Idee woran das liegen koennte?

Olaf

[Rolf M. (rmagnus)]

> Hat da jemand eine Idee woran das liegen koennte?

Liegt es denn wirklich an Qt? Du könntet die Schnittstelle ja mal mit 
einem seriellen Terminal öffnen und schauen, was dort rauskommt.

[Sven P. (Gast)]

Ists Windows?
Läuft da noch irgendein dämlicher Maustreiber, der versucht, eine 
serielle Maus anzusprechen..?

[Olaf (Gast)]

> Liegt es denn wirklich an Qt?

Das frage ich mich auch. Bloederweise ist ja mittlerweile an meiner 
Umgebung alles anders. Leider laeuft hterm auf dem neuen System nicht 
mehr (libary-versionen, seufz) und mit minicom hab ich es gerade nicht 
geschafft was zu senden, oder es kam jedenfalls keine Antwort.
Da muss ich aber noch was graben oder ein kleines Testprogramm in C 
direkt auf dem Port hinzimmern.

> Ists Windows?

Das ist linux. Allerdings auch da koennte es sein das da irgendwas 
anderes den Port befingert. Zumal diese ueberzaehligen Zeichen so alle 
1-2s im Buffer auftauchen. Also relativ lahm. Allerdings wuerde ein 
getty ja eher den Oszi verwirren weil es was rausschickt. Das Oszi 
antwortet aber korrekt wenn man von den ueberzaehligen Zeichen absieht.

Ist jedenfalls mal ein interessantes Problem. :)

Olaf

[Jim M. (turboj)]

Schaul mal (z.B. mit lsof) nach ob der Port noch woanders geöffnet ist.

NetworkManager z.B. öffnet USB CDC Ports um USB 3G Modems anzusteuern. 
Das kann man sicherlich auch irgendwo unterbinden.

[kontext (Gast)]

Kannst Du mal ein bisschen zusammenhängenderen Code posten?

Vom Öffnen der Schnittstelle, senden des Kommandos, Einlesen der Antwort 
bis zur Ausgabe des Strings.

Das irgendein anderes Programm oder der NetworkManager heimlich Daten in 
den Port schreibt, wäre ziemlich abenteuerlich.

[Frank K. (fchk)]

NetworkManager nicht, aber der ModemManager wäre ein Kandidat. Wenn Du 
keine LTE-Modems hast, kannst Du den ohne Probleme und ohne Nachteile 
deinstallieren.

fchk

[Olaf (Gast)]

Also ich weiss zwar noch nicht wo es her kommt, aber es liegt nicht an 
Qt!

Ich hab gerade mal ein Programm mit dem Namen "scriptcommunicator" 
installiert. Das ist ein ziemlich cooles Terminalprogramm fuer Linux und 
Windows. (anschauen!)
https://sourceforge.net/projects/scriptcommunicator/

Sobald ich da den Port zum Oszi aufmache kommen die falschen Bytes rein.
Entweder das liegt am Kernel oder sonst wie am System. Und zwar so 4-5x 
pro
Sekunde.
Hm....

Olaf

[Frank K. (fchk)]

apt remove modem-manager

jetzt besser?

fchk

[Olaf (Gast)]

Ich hab den Modemmanager mal gerade entfernt. Hat aber nichts geändert.

Hier hat einer genau mein Problem mit anderer Hardware:

https://stackoverflow.com/questions/32831461/generic-usb-serial-device-continuously-gives-1

Allerdings funktioniert seine Loesung bei mir auch nicht. Muss ich noch 
weiter schauen...

Olaf

[Olaf (Gast)]

Interessanterweise geht es jetzt doch...
Keine Ahnung was da schief gegangen ist. Das FTDI Geraet ist dem Kernel
eigentlich bekannt.

Olaf

[Rolf M. (rmagnus)]

Jim M. schrieb:
> Schaul mal (z.B. mit lsof) nach ob der Port noch woanders geöffnet ist.

Hast du das mal gemacht? Vielleicht findest du damit den Übeltäter.