Hi, ich experimentiere hier gerade mit einem BeagleBone Black sowie ein wenig Bare-Metal Programmierung herum. Unter anderem habe ich das usb_dev_serial-Beispiel aus der Starterware am Wickel (damit soll serielle Kommunikation per USB möglich sein). Der Code funktioniert problemlos, leider taucht das Gerät aber als /dev/ttyACM0 statt als /dev/ttyUSB0 auf. Das führt dazu, dass immer mal ein paar AT-Sequenzen gesendet werden (das scheint das Kernelmodul zu machen). Da das Gerät aber als reine serielle (USB-)Schnittstelle verwendet werden soll: wie identifiziert der Linux-Kernel mein BBB denn als ACM-Gerät? Vendor- und Product-ID habe ich bereits zu was unbekanntem geändert, der Control Interface String heißt auch nicht mehr "ACM Control Interface" (ich hatte vermutet, dass vielleicht das "ACM" in diesem String geparst wird). Woher könnte das sonst noch kommen - warum erkennt der Kernel das Teil nicht als reine serielle Schnittstelle sondern popelt immer das ACM rein? Danke!
:
Gesperrt durch Moderator
Du musst die USB Device Class auf CDC ändern und auf die ensprechenden Kommandos reagieren. VID/PID und String Descriptoren haben damit rein gar nichts zu tun.
Seit einem Ubuntu-Update vor einigen Monaten ist bei mir das ttyACM0 verschwunden. Hatte mich damals aber nicht weiter gestört, Ubuntu hatte keine AT Kommandos gesendet. Vielleicht finden sich unter /var/log Hinweise, welches Programm die Kommandos sendet.
Der Modem-Manager greift darauf zu und sendet AT-Kommandos. Ich hab mir mal irgendwann folgendes notiert:
1 | ########################################################################### |
2 | Linux sendet AT+GACP an ttyACMx? |
3 | So schaltet man das ab: |
4 | in /etc/udev/rules.d/10-local.rules diese Zeile einfügen: |
5 | ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", ENV{ID_MM_DEVICE_IGNORE}="1"
|
6 | natürlich die korrekte Vendor und ProduktID benutzen ;) |
7 | ########################################################################### |
Damit wird aus ttyACMx nicht ttyUSBx, aber es wird nicht mehr fälschlicherweise vom Linux als Modem "missbraucht".
Satz K. schrieb: > Der Code funktioniert problemlos, leider taucht das Gerät aber als > /dev/ttyACM0 statt als /dev/ttyUSB0 auf. Das führt dazu, dass immer mal > ein paar AT-Sequenzen gesendet werden (das scheint das Kernelmodul zu > machen). Mit den AT Commands : Der Kernel macht da nichts garantiert > Da das Gerät aber als reine serielle (USB-)Schnittstelle verwendet > werden soll: wie identifiziert der Linux-Kernel mein BBB denn als > ACM-Gerät? Vendor- und Product-ID habe ich bereits zu was unbekanntem > geändert, der Control Interface String heißt auch nicht mehr "ACM > Control Interface" (ich hatte vermutet, dass vielleicht das "ACM" in > diesem String geparst wird). > > Woher könnte das sonst noch kommen - warum erkennt der Kernel das Teil > nicht als reine serielle Schnittstelle sondern popelt immer das ACM > rein? > Das kommt meist vom Modemmanager, der in Verbundung mit udev das Chaos macht. Google mal PL2303 blacklisten > Danke!
Christian R. schrieb: > Du musst die USB Device Class auf CDC ändern und auf die ensprechenden > Kommandos reagieren. VID/PID und String Descriptoren haben damit rein > gar nichts zu tun. Die ist schon auf USB_CLASS_CDC...
Hier steht eine kurze Erkärung zu ttyUSBx und ttyAMCx https://www.rfc1149.net/blog/2013/03/05/what-is-the-difference-between-devttyusbx-and-devttyacmx/ USB_CLASS_CDC meldet sich (zumindest bei mir) als ttyACMx an.
Detlef Kunz schrieb: > ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", > ENV{ID_MM_DEVICE_IGNORE}="1" Ich habe bei mir
1 | ATTR{idVendor}=="1234", ATTR{idProduct}=="5678", ENV{ID_MM_DEVICE_IGNORE}="1" |
eintragen müssen, aber damit geht es, es werden keine AT-Kommandos mehr dazwischengefunkt.
:
Bearbeitet durch User
Detlef Kunz schrieb: > USB_CLASS_CDC meldet sich (zumindest bei mir) als ttyACMx an. Bei mir auch. Ganz eigenwillig: wenn ich den control interface description string (der im Original "ACM Control Interface" heißt) ganz weglasse, dann taucht das Gerät weder als /dev/ttyACM0 noch als irgend was anderes auf...
Satz K. schrieb: > Da das Gerät aber als reine serielle (USB-)Schnittstelle verwendet > werden soll: wie identifiziert der Linux-Kernel mein BBB denn als > ACM-Gerät? Ob das was mit dem Kernel zu tun hat? Ich lehne mich mal aus dem Fenster: Wenn sich Deine Firmware an die USB-Spezifikation hält, dann geht das auch mit Linux? Klaus
Klaus schrieb: > Satz K. schrieb: >> Da das Gerät aber als reine serielle (USB-)Schnittstelle verwendet >> werden soll: wie identifiziert der Linux-Kernel mein BBB denn als >> ACM-Gerät? > > Ob das was mit dem Kernel zu tun hat? > Ich lehne mich mal aus dem Fenster: Wenn sich Deine Firmware an die > USB-Spezifikation hält, dann geht das auch mit Linux? > > Klaus Das Gerät selbst meldet, das es ein ACM-Device ist. Das steht nicht in den Desciptor Strings, sondern als Zahlenwert in den Descriptoren.
Detlef Kunz schrieb: > Das Gerät selbst meldet, das es ein ACM-Device ist. > Das steht nicht in den Desciptor Strings, sondern als Zahlenwert in den > Descriptoren. Aber genau diese Deskriptoren legen die Funktion Deines Gerätes fest. Wenn bei Dir also in den Deskriptoren ein ACM Gerät definiert wird, und sich dann Dein Gerät als ACM Gerät anmeldet, dann würde ich sagen: Alles Ok. Klaus
Klaus schrieb: > Wenn bei Dir also in den Deskriptoren ein ACM Gerät definiert wird, und > sich dann Dein Gerät als ACM Gerät anmeldet, dann würde ich sagen: Alles > Ok. Dann wiederhole ich doch gleich mal meine ursprüngliche Frage: WELCHE Deskriptoren legen dieses Verhalten fest?
Zeig doch mal, was Du als Descriptor verwendest. Wo kommt das her?
Satz K. schrieb: > Klaus schrieb: >> Wenn bei Dir also in den Deskriptoren ein ACM Gerät definiert wird, und >> sich dann Dein Gerät als ACM Gerät anmeldet, dann würde ich sagen: Alles >> Ok. > > Dann wiederhole ich doch gleich mal meine ursprüngliche Frage: WELCHE > Deskriptoren legen dieses Verhalten fest? Das ganze ist ziehmlich komplex. Die Descriptoren bauen aufeinander auf. Änderst Du den Typ des Devices, dann must Du meist auch eine Menge andere Dinge ändern, einschießlich der Software, die die Steuerung des Datenverkehrs regelt. Also fangen wir mal beim Device Desriptor an: Wenn Du ein einfaches Interface hast, steht da im Feld bDeviceClass sicher 0x02 drin, was bedeutet, Du hast ein CDC-Device (CDC --> communications device class) sollte da 0xEF drin sein, dann wird es richtig schwierig, weil dann mehrere Interface enthalten sein können. Also wenn Du ein CDC-Device hast, dann bleibt als brauchbare Subclass nur Abstract Control Model (also ACM). Aber man brauchte schon deine Descriptoren um das zu klären. Ändern wird man dann auch nichts könne, weil wenn Du da was änderst, dann werden andere Treiber geladen (es sei denn man trickst), das erfordert wieder ander Kommunikatinssoftware in µC (wenn Du dir die Sourcen zu deinem USB-Interface anschaust, wirst Du sicher feststellen das da irgendwas von CDC drin steht, da ist das Zeug für die Kommunikation als CDC/ACM-Device drin).
:
Bearbeitet durch User
Satz K. schrieb: > Dann wiederhole ich doch gleich mal meine ursprüngliche Frage: WELCHE > Deskriptoren legen dieses Verhalten fest? Leider hat Deine Frage einen größeren Umfang wie z.B.: Welches Bit muss ich setzen, damit die LED angeht? Bei USB musst Du Dich selber etwas damit auseinander setzen, oder Du hängst einen FTDI an den UART: http://www.lvr.com/usb_virtual_com_port.htm
Satz K. schrieb: > Dann wiederhole ich doch gleich mal meine ursprüngliche Frage: WELCHE > Deskriptoren legen dieses Verhalten fest? Dann gibt's ne passende Antwort: Lies die USB-Doku. Ohne die wenigstens EINMAL durchgekäut zu haben, wirst du ewig bloß im Nebel stochern, ohne was zu kapieren. Und: Soweit ich mich erinnere, heißt der entscheidende Descriptor Device Descriptor. Dort werden Geräteart und Unterart festgelegt. W.S.
W.S. schrieb: > Dann gibt's ne passende Antwort: Lies die USB-Doku. Ohne die wenigstens > EINMAL durchgekäut zu haben, wirst du ewig bloß im Nebel stochern, ohne > was zu kapieren. Das wirft die nächste Frage auf: wo gibt's die? Die Codekommentare in meinem Deskriptor verweisen für den Subtyp auf eine USB-IF, so wie es aussieht, bekommt man die Doku aber nur als (zahlendes) Mitglied des USB-Forums?
Ich habe gerade das Problem mit den Arduino mit Opensuse. Sie lassen sich nicht programmieren. Sie melden sich als /dev/ttyACM0 an. Den Modemmanager habe ich schon deinstalliert klappt immer noch nicht. Auch mit root rechten klappt es nicht. Das Programmieren startet, die LED zuckt entsprechen. Kann leider das Programmieren nicht vollständig durchführen. Ich kann das Board auch auslesen welcher Typ und Seriennummer. Aber eben das Programmieren geht in die Hose.
René D. schrieb: > Das Programmieren startet, die LED zuckt entsprechen. Kann leider das > Programmieren nicht vollständig durchführen. Mit welchem Programm? Welcher Konfiguration? Und wie lautet die Fehlermeldung? Schau dir mal an, wie man avrdude im Kommandofenster verwendet und mit dem Parameter -v detaillierte Meldungen aktiviert. Diese helfen dabei, diese Frage zu klären. Jetzt google nach avrdude Anleitungen. Für's nächste mal: Hänge dich nicht an einen uralten Thread, wo es auch noch um ein anderes Problem geht. Aufgrund des Titel lockt er nämlich die falschen Leute an.
Stefan ⛄ F. schrieb: > Für's nächste mal: Hänge dich nicht an einen uralten Thread, wo es auch > noch um ein anderes Problem geht. Ich mach daher mal dicht hier. Bitte als neuen Thread mit passendem Titel posten.
Thread beobachten
Seitenaufteilung abschalten