Hallo.
Ich hab hier schon einige Threads sowie im Internet versucht etwas
greifbares zufinden, aber erfolglos. Ich hab ein Gerät (erstmal
unwichtig) das ich gerne in Linux ansprechen möchte. Das Problem liegt
beim cp210x Treiber. Dieses Gerät ist mit einem Silabs 2101 Chip
ausgerüstet. In Windows konnte ich es in Python ohne Probleme
ansprechen. Device öffnen - Test-Sequenz senden - Rückantwort korrekt -
Schnittstelle schließen. Kein Problem. In Linux hab ich damit aber ein
Problem. Ich hab erst wie beschrieben die Source-Kernel-Treiber von
SiLabs gezogen, kompiliert und entsprechend ins Modul-Verzeichnis
reingestellt. Nach einbinden in den Kernel kommt folgende Meldung:
1
[14158.900597] usbcore: registered new interface driver usbserial_generic
2
[14158.900733] usbserial: USB Serial support registered for generic
3
[14158.900758] usbserial_generic 2-2:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes.
4
[14158.900761] usbserial_generic 2-2:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver.
[14158.901000] usb 2-2: generic converter now attached to ttyUSB0
7
[14158.915438] usbcore: registered new interface driver cp210x
8
[14158.915581] usbserial: USB Serial support registered for cp210x
Ich denke aber es sollte trotzdem funktionieren, oder muss ich jetzt
trotz dieser Meldungen etwas unternehmen/melden damit ein Treiber
erstellt wird ? Ich möchte das aber nicht machen, da es ja privat ist.
Ich hab dann das Python-Script kurz in C umgeschrieben. Das seltsame
ist, ich kann zwar die Test-Sequenz senden, aber es kommt nichts zurück.
Nur wenn das Interface auf diese Test-Sequenz anspricht, ist alles OK.
Bin am verzweifeln, denn ich denke es ist nur noch ein kleiner Schritt
bis das Interface anspricht... denke ich. Ach ja, ich arbeite mit
Kubuntu 18.04 bionic.
Moderne Kernel sollten den CP210x eigentlich ohne Modifikationen
erkennen.
Eventuell sind die Meldungen eine Nebenwirkung des Silabs Code.
Versuche es mal mit dem default Kernel einer neueren Distribution ohne
die Slabs Änderungen einzuspielen.
Übrigens werde ich aus der Fehlerbeschreibung nicht schlau - ich kann
nicht nachvollziehen was bei Dir tut und was nicht. Die seriellen
Leitungen des CP210x könnte man zum Testen an ein DSO anschließen.
Hallo Jim.
Erstmal Danke für die Antwort. Ich habe beide Kernel-Module ausprobiert.
Das eigene Kernel-Modul von Linux und den von SiLabs. Bei beiden wird
dann das /dev/ttyUSB0 aktiv bzw. generiert. Im Augenblick weiß ich nicht
genau wo der Fehler herrührt. Mein Gerät(Interface) ist ja so gesehen
nicht defekt, denn in Windows kann ich das Gerät ohne Probleme
ansprechen. Nur in Linux halt nicht. Was ich nicht weiß, wozu die
PID/VID gut sein sollte. OK, damit kann man identifizieren von welchem
Hersteller (nicht SiLabs) das Gerät stammt, aber es gibt auch Hersteller
die sich eben nicht in die "Liste" eintragen. Oder wird eventuell mit
der PID/VID tatsächlich intern im cp210x Chip etwas
"freigeschaltet"/enabled/Adressenzugriff ?
Deshalb denke ich es muss am Treiber liegen. Ich werde nochmals den
originalen Linux-Treiber aktivieren.
Gruß
Im Schnelldurchgang:
In deinen Kernelmeldungen fehlt die wichtige Meldung "New USB device
found, idVendor=..., idProduct=...". Wenn die gar nicht da ist, dann ist
was sehr im Argen. Das USB-System erkennt nicht mal die Anwesenheit des
Gerätes. Dann ist das kein Problem des cp210x-Treibers. Wenn du die
Meldung nur unterschlagen hast, die Zahlen sind wichtig, das ist die VID
und PID.
Der Generic Treiber alleine, ohne CP210x, nützt dir nichts. Der kann nur
"Durchpfiff" 1:1 Übertragung von Rohdaten.
Der CP210x Treiber ist seit 2.6.irgendwas Teil des Kernels, also seit
"ewig". Daher schmeiß den selbst gebauten Treiber erst einmal wieder
raus.
Mit modinfo, oder notfalls im Sourcecode, nachsehen welche VID/PIDs in
den Treiber einkompiliert sind (die "alias: usb:" Felder). In aktuellen
Kernel-Versionen sind dass etwa 180 VID/PIDs die der Treiber direkt
kennt.
Ist deine VID/PID nicht dabei wird es etwas haarig. Je nach
Linux-Distribution werden andere Mechanismen bevorzugt die VID/PID
nachzutragen. Manche verwenden udev-Regeln. Andere Einträge unter
/etc/modprobe.d/. Wieder andere manipulieren
/sys/bus/usb-serial/drivers/cp210x/new_id. Manche fügen direkt irgendwo
einen Aufruf von "modprobe cp210x vendor=... product=..." oder "insmod
cp210x vendor=... product=..." in ein Startscript ein. Googlen, googlen,
goolen, aber nicht wild jedes Rezept ausprobieren! Statt dessen
sorgfältig nachdenken ob ein Rezept für dein Linux passt! EIn guter
Hinweis ist, wenn man sieht, dass etwas auf dem eigenen Linux schon so
für andere Geräte gemacht wird.
Wenn es das Linux zulässt gehe ich meist hin und füge eine Datei unter
/etc/modprobe.d/ ein, mit dem Namen des Gerätes und der Fileextension
".conf". Darin
1
option cp210x vendor=... product=...
Ein Linux das /etc/modprobe.d/ unterstützt bastelt daraus automatisch
einen "modprobe cp210x vendor=... product=..." Aufruf zur richtigen
Zeit.
Erst wenn alle typischen Möglichkeiten nicht funktionieren den Treiber
selber bauen. Dabei nicht den Sourcecode von SiLabs verwenden, sondern
genau den für deine Linux-Distribution, genau für den Kernel deiner
Distribution, mit allen Patches die eventuell in deiner Distribution vom
Distributor zum Treiber hinzugefügt wurden. Die VDI/PID im Code
eintragen, neu bauen und den Originaltreiber ersetzen.
Hannes J. schrieb:> Im Schnelldurchgang:>> In deinen Kernelmeldungen fehlt die wichtige Meldung "New USB device> found, idVendor=..., idProduct=...". Wenn die gar nicht da ist,> .......> Der Generic Treiber alleine, ohne CP210x, nützt dir nichts. Der kann nur> "Durchpfiff" 1:1 Übertragung von Rohdaten.>
Das mit dem Generic Treiber dachte ich mir auch. War mir auch klar das
der cp210x auch mit dem Generic treiber gebraucht wird.
>> Der CP210x Treiber ist seit 2.6.irgendwas Teil des Kernels, also seit> "ewig". Daher schmeiß den selbst gebauten Treiber erst einmal wieder> raus.>> Mit modinfo, oder notfalls im Sourcecode, nachsehen welche VID/PIDs in> den Treiber einkompiliert sind (die "alias: usb:" Felder). In aktuellen> Kernel-Versionen sind dass etwa 180 VID/PIDs die der Treiber direkt> kennt.>> Ist deine VID/PID nicht dabei wird es etwas haarig. Je nach> Linux-Distribution werden andere Mechanismen bevorzugt die VID/PID> nachzutragen. Manche verwenden udev-Regeln. Andere Einträge unter> /etc/modprobe.d/. Wieder andere manipulieren> /sys/bus/usb-serial/drivers/cp210x/new_id. Manche fügen direkt irgendwo> einen Aufruf von "modprobe cp210x vendor=... product=..." oder "insmod> cp210x vendor=... product=..." in ein Startscript ein. Googlen, googlen,> goolen, aber nicht wild jedes Rezept ausprobieren! Statt dessen> sorgfältig nachdenken ob ein Rezept für dein Linux passt! EIn guter> Hinweis ist, wenn man sieht, dass etwas auf dem eigenen Linux schon so> für andere Geräte gemacht wird.>> Wenn es das Linux zulässt gehe ich meist hin und füge eine Datei unter> /etc/modprobe.d/ ein, mit dem Namen des Gerätes und der Fileextension> ".conf". Darin>
1
> option cp210x vendor=... product=...
2
>
... so dachte ich mir das auch.
> Ein Linux das /etc/modprobe.d/ unterstützt bastelt daraus automatisch> einen "modprobe cp210x vendor=... product=..." Aufruf zur richtigen> Zeit.
Auch das dachte ich mir.
Wenn ich dem cp210x diese Optionen mitgebe kommt in der dmesg folgende
Meldung:
Diese Optionen muss ich dem Kernel-Modul usbserial mitgeben (wird
wahrscheinlich dann dem cp210x durchgereicht, erst dann wird
auch automatisch das /dev/ttyUSB0 generiert, sonst nicht.
>> Erst wenn alle typischen Möglichkeiten nicht funktionieren den Treiber> selber bauen. Dabei nicht den Sourcecode von SiLabs verwenden, sondern> genau den für deine Linux-Distribution, genau für den Kernel deiner> Distribution, mit allen Patches die eventuell in deiner Distribution vom> Distributor zum Treiber hinzugefügt wurden. Die VDI/PID im Code> eintragen, neu bauen und den Originaltreiber ersetzen.
Ich poste hier mal lsusb vor und nach dem einstecken:
Vor:
1
Bus 001 Device 002: ID 8087:8001 Intel Corp.
2
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
3
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
4
Bus 002 Device 004: ID 0bda:b728 Realtek Semiconductor Corp.
5
Bus 002 Device 003: ID 13d3:5744 IMC Networks
6
Bus 002 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
7
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Nach einstecken (Sorry musste die PID/VID mit xy auskommentieren):
1
Bus 001 Device 002: ID 8087:8001 Intel Corp.
2
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
3
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
4
Bus 002 Device 004: ID 0bda:b728 Realtek Semiconductor Corp.
5
Bus 002 Device 003: ID 13d3:5744 IMC Networks
6
Bus 002 Device 002: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
7
Bus 002 Device 005: ID xxxx:yyyy Cygnal Integrated Products, Inc.
8
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Und die dmesg nach einstecken(Sorry auch hier musste ich PID/VID
auskommentieren):
1
[ 266.212424] usb 2-2: new full-speed USB device number 5 using xhci_hcd
2
[ 266.362369] usb 2-2: New USB device found, idVendor=xxxx, idProduct=xxxx
3
[ 266.362376] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
4
[ 266.362380] usb 2-2: Product: USB Sensor Interface Device
5
[ 266.362385] usb 2-2: Manufacturer: Silicon Labs
6
[ 266.362388] usb 2-2: SerialNumber: xxxx
Ich hab mir gerade den Source-Code des cp210x von SiLabs wegen der
Firmen-Liste angeschaut. Die PID/VID kommt hier tatsächlich nicht vor.
Warum erscheint im Source-Code nicht der Cygnal-Treiber ?
D.h. es wird nur der Generic-Treiber angesprochen. Würde es etwas nützen
wenn ich die "echte" PID/VID des Gerätes bekommen würde ? Wenn ich die
PID/VID hätte, dann gibt es aber trotzdem keinen Treiber der diese
PID/VID schon implementiert hätte.
Warum funktioniert dann die ganze Geschichte in Windows ? Wie ich gehört
habe ist das der ganz normale Windows-VCP-Treiber den man auch von der
SiLabs-Homepage runterladen kann.
Gruß
Hallo.
Ich bin im Augenblick selber etwas ratlos, denn ich habe den Verdacht
dass erst die Firma mit dem Produkt die PID/VID melden muss/darf und
entsprechend dann der modifizierte Treiber cp210x publiziert wird. Ich
vermute das vorher gar nichts zum laufen kommt. Ich hab mal die
angezeigte PID und VID spasseshalber im Source-Code des
SiLabs-Source-Treiber in die Liste eingetragen und kompiliert in der
Hoffnung dass das Gerät auf die Sequenz anspricht, hat aber nichts
gebracht. Klar es gibt noch andere Möglichkeiten aber ich wollte nicht
so einen großen Aufwand (z.B. über DSO Signale analysieren) betreiben.
Gibts denn noch eine andere Möglichkeit wie ich event. per Software das
Gerät ansprechen kann ?
Gruß
Blode Frage, aber hast Du nach dem Anstecken ein /dev/ttyUSB* mehr im
/dev Verzeichnis? Das nach dem Abstecken auch verschwindet?
Wenn ja, dann sollte der Linux Treiber funktionieren.
Übrigens können Dir unter Linux diverse Programme u.U. bei seriellen
Schnittstellen dazwischen funken.
Schau mal mit "lsof /dev/ttyUSB0" nach...
Hallo Thorsten.
Die PID/VID wird bei mir angezeigt. Als ich die Liste mir anschaute
hatte ich den Eindruck das passt in etwa mit den angezeigten
Hex-Nummern.
Ich könnte das mal reinkompilieren, nur die 000f sieht etwas seltsam
aus.
Ich werds mal reinkompilieren....
Ich hab gerade eben festgestellt... wenn ich die falsche PID/VID also
10c4:000f übergebe dann kommt das Device nicht hoch. Also ist die
angezeigte PID/VID doch korrekt auch wenn sie nicht in der Liste
auftaucht.
Gruß
Hallo Jim.
Also lsof /dev/ttyUSB0 zeigt nichts an. Es läuft bei mir auch nichts im
Hintergrund. Ich hab den ModemManager extra deshalb rausgeschmissen
damit nichts im Hintergrund belegt wird.
Stecke ich das Gerät aus, verschwindet das Device, klemm ich es wieder
dran ist das Device auch wieder da.
Da gibt es aber folgendes was für mich etwas seltsam ist....
Wie Hannes etwas weiter oben beschreibt sollte ich die Optionen an den
cp210x übergeben. Da streikt aber der Treiber wie etwas weiter oben im
Thread zu sehen.
Ich mach folgendes:
unter root:
modprobe -r cp210x
modprobe -r usbserial
modprobe usbserial vendor="0x..." product="0x...."
modprobe cp210x
Erst in dieser Reihenfolge wird auch das Device generiert. Dann reagiert
es auch wie beschrieben. Nur auf die Sequenz halt nicht.
Gruß
Laut Ausgangslog wuerde ich auch sagen, dass das Device erkannt wird
(wegen ttyUSB0). Wahrscheinlich hast Du beim Lesen einfach was falsch
gemacht, warum benutzt Du das pythonscript nicht auch unter Linux mal,
wenn Du weisst, dass es klappt? Es wird doch vermutlich auf pySerial
basieren, oder?
Hallo devzero.
Genau das hab ich auch gemacht.
Ich mußte nur statt \\\\.\\COM... auf /dev/ttyUSB0 umsetzen aber auch
hier genau das gleiche Verhalten.... es kommt auf die Sequenz nichts
zurück.
Ach ja... ich hab pySerial installiert.
Wir haben ja gesehen der Treiber reagiert richtig. Dann müßte doch die
Test-Sequenz 1:1 an das Gerät weitergereicht werden. Ich überprüfe ja
was gesendet wurde und das ist die Anzahl der Bytes der Testsequenz.
Aber nach dem timeout wird mir gesagt Anzahl der empfangenen Bytes=0.
Gruß
Das Erste wäre ja wohl ein Loopback Test. Rxd mit TxD verbinden und dann
in irgendeinem Terminalprogramm (z.B. cutecom oder Hammer Terminal)
etwas Senden. Das muss zurück kommen, ganz unbahängig von Baudrate und
den anderen Optionen.
Ich verstehe nicht, warum du den Treiber mit bestimmten Optionen
versorgen willst, obwohl er nach Plug&Play Prinzip bereits funktioniert.
Diese Parameter brauchst du nur, wenn der Kernel mit der Vendor-ID und
Device-ID nichts anfangen kann und das Gerät als "Unbekannt" meldet. Das
ist bei Dir aber gemäß deinem Logauszug im ersten Beitrag nicht der
Fall.
Hallo.
Ich möchte erst mal allen Danken die mir hier helfen.
Mittlerweile glaube ich aber dass das ganze extrem schwieriger ist als
gedacht. Gestern Abend dachte ich, dass wenn ich die PID/VID selber
durch ein Python-Script von SiLabs ändere, das ich vielleicht das Gerät
zum laufen bekomme.
Abgesehen davon, dass das Python-Script in Windows gar nicht lief, habe
ich durch die Homepage von Silabs erfahren, dass wenn man die PID/VID in
Windows ändert, der eingespielte Treiber dann Probleme machen kann und
event. das Gerät gar nicht mehr anspricht. Klar... man zieht sich ja den
eigenen Ast auf dem Sitzt weg....
Es wäre zwar schön gewesen wenn ich den SiLabs-Chip auf
Werkseinstellungen zurücksetzen hätte können. Dadurch dass die Firma des
Gerätes selber eine PID/VID einspielt, könnte ich mir vorstellen, dass
event. dadurch ein ansprechen in Linux vielleicht unbeabsichtigt
verhindert wird. Außerdem hatte ich den Eindruck auf der Homepage von
SiLabs, dass es viele User gibt die mit den Treibern richtig Probleme
haben...und erst recht bei Windows 10.
Mir bleibt nichts anderes übrig als dass wenn ich mit der Firma nächste
Woche in Kontakt komme, vielleicht mal Frage was da in den SiLabs-Chip
reinprogrammiert wird.
Ein öffnen des Gerätes möchte ich nicht machen, da ich event. dann
Leiterbahnen trennen müsste.
Gruß
U. B. schrieb:> Mir bleibt nichts anderes übrig als dass wenn ich mit der Firma nächste> Woche in Kontakt komme, vielleicht mal Frage was da in den SiLabs-Chip> reinprogrammiert wird.
Schau zuerst einfach mal ins CP210x Datenblatt. IIRC war der Speicher
für VID/PID ein OTP, da kann man also nicht einfach neue Nummern
reinschreiben.
Und ja, bei Geräten wo man die Nummern ändern kann schießt man sich den
Windows Treiber ab, denn in dessen .inf stehen die zwecks
Identifizierung drin. Und ab Win 8 sind .inf zwingend signiert und damit
nur schwer änderbar.
Im übrigen gibt es ein paar kleinere Unterschiede bei Windows/Linux
Programmierung, über die Dein uns unbekanntes Python Programm IMHO
durchaus stolpern könnte.
U. B. schrieb:> Ein öffnen des Gerätes möchte ich nicht machen, da ich event. dann> Leiterbahnen trennen müsste.
Das man sowohl bei Windows als auch bei Linux die rohen USB Pakete
aufzeichnen und analysieren kann, ist Dir bekannt?
Das war mir bekannt....
Letztendlich...
Die PID/VID war ja in der "Firmen-"Liste im Kernel nicht zu finden.
Wenn man die PID/VID Kernel.org melden würde, dann müßte doch ein
Eintrag in die Liste bzw. im Kernel-Modul des cp210x stattfinden und es
müßte dann irgendwann ein Kernel/Treiber rauskommen wo diese Nummer
wiederzufinden ist.
Ich könnte mir vorstellen, dann wird das Gerät event. ansprechbar.
Wenn das so wäre, so müßte ich halt die Firma informieren.
Gruß
Thread beobachten
Seitenaufteilung abschalten