Udev und Eineiige Zwillinge - mehrere pl2303

    Ich benötige mehrere serielle Schnittstellen. Dafür habe ich einige USB2Serial Adapter angeschlossen.


    Mein Problem ist, dass ich momentan zwei PL2303 Supermarkt-Adapter nutze, welche die gleiche Vendor und Product ID nutzen (die Bits haben die sich wohl gespart).
    Verschlimmert wird das ganze noch dadurch, dass Bus und Device ID pseudozufällig vergeben werden. Das Ergebnis ist, dass die PL2303s nach jedem Systemstart ein anderes ttyUSB Device nutzen.


    Ich habe das Problem notdürftig mit einem Script umgangen, welches beim Start die USB Ports prüft und die Devices per Systemlink anlegt.


    Kennt jemand eine Möglichkeit das sauberer zu lösen? ( Außer FTDI Adapter zu kaufen ;) )

    2.6.29-gentoo-r5, vdr-1.7.9, xine-vdpau-284, vdr-xine 0.93 - 5050e, M3A78-EM, Postville, 2xTTS21600

    PearlHD text2skin

    Einmal editiert, zuletzt von mapovi ()

    Hi,


    Zitat

    Original von mapovi
    gleiche Vendor und Product ID


    das ist bei gleichem Produkt normal.


    Kannst Du mal mit

    Code
    lsusb -v

    auslesen, ob die Dinger nicht auch noch eine iSerial oder was Ähnliches haben?
    Dann könnte man den Symlink mit einer Udev-Regel automatisieren.


    Grüße joker

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

    Danke für die Antworten


    @joker4791


    Zitat

    Dann könnte man den Symlink mit einer Udev-Regel automatisieren.


    Das ist ja mein Problem, die Ausgabe von lspci -v ist leider identisch (bis auf Bus und Device).


    Rincewind99


    Zitat

    Falls die Firmware auf einem EEPROM sitzt könntest du versuchen, die Firmware anzupassen.


    Werde ich mir mal anschauen.

    2.6.29-gentoo-r5, vdr-1.7.9, xine-vdpau-284, vdr-xine 0.93 - 5050e, M3A78-EM, Postville, 2xTTS21600

    PearlHD text2skin

    Zitat

    Original von mapovi
    Kennt jemand eine Möglichkeit das sauberer zu lösen? ( Außer FTDI Adapter zu kaufen ;) )


    Also ich hab hier auch zwei Devices, die den FTDI haben und sich trotzdem gerne mal in der Reihenfolge getauscht haben. Ich hab im Netz die UDEV Rule hier gefunden, die zumindest mit den FTDI Dingern gut funktioniert:

    Code
    SUBSYSTEMS=="usb", ATTRS{idProduct}=="xxxx", ATTRS{idVendor}=="yyyy", SYMLINK+="ttyUSB_%b", KERNEL=="ttyUSB[0123456789]", MODE="0666"


    Für xxxx und yyyy musste natürlich die Product und Vendor ID von deinem USB-Adapter eintragen.


    Damit ist die /dev/ttyUSB_xxx Bezeichnung abhängig vom USB-Port wo das Teil drin steckt. Solange man den Adapter im selber USB-Port lässt, hat er jetzt anscheinend auch immer den gleiche Namen.
    Es kommen dann z.B. so ne Bezeichnungen bei raus:
    /dev/ttyUSB_1-2.1
    /dev/ttyUSB_1-2.2

    Zitat

    Original von mapovi
    @Ioannis


    Das Problem ist, dass sich ATTRS{idProduct}=="xxxx" und ATTRS{idVendor}=="yyyy" der Adapter nicht unterscheiden. :)


    Das macht ja nix, tun sie ja bei mir auch nicht. Das entscheidende ist wohl das "%b" in SYMLINK+="ttyUSB_%b". Denn der Port wo die Dinger drin stecken, wird sich ja wohl auch bei Dir unterscheinden, oder? ;)

    @Ioannis


    Steht das "%b" nicht für BUS?* Der ändert sich bei mir auch.
    Kann momentan nicht rebooten. Werde es aber später trotzdem mal probieren ob %b gleich bleibt.
    Kann man die Vergabe der BUS ID beeinflussen?


    EDIT :* Man udev: %b ist die Bus ID.

    2.6.29-gentoo-r5, vdr-1.7.9, xine-vdpau-284, vdr-xine 0.93 - 5050e, M3A78-EM, Postville, 2xTTS21600

    PearlHD text2skin

    Einmal editiert, zuletzt von mapovi ()

    Hi,


    wenn die Wandler unterschiedliche Seriennummern haben, sollte sich mit UDEV was anfangen lassen. Für FTDI-Wandler habe ich mir über die Seriennummern Regeln angelegt, die Sym-Links erzeugen. Dem Aurora-Plugin kann ich dann als Device-Namen '/dev/auroraController' übergeben. Das läßt sich auch einfacher merken als '/dev/ttyUSB27'.


    Gruß
    e9hack

    e9hack

    Code
    wenn die Wandler unterschiedliche Seriennummern haben


    Haben sie ja eben nicht.

    Code
    Für FTDI-Wandler habe ich mir über die Seriennummern Regeln angelegt, die Sym-Links erzeugen


    Die FTDI-Wandler sind bei mir auch unproblematisch.


    @Ioannis
    Habe es getestet, %b steht für BUS und DEVICE ID und ändert sich fröhlich bei jedem Systemstart. Trotzdem Danke für deine Mühe.
    Wie hast du udev so konfiguriert, dass die IDs gleich bleiben?

    2.6.29-gentoo-r5, vdr-1.7.9, xine-vdpau-284, vdr-xine 0.93 - 5050e, M3A78-EM, Postville, 2xTTS21600

    PearlHD text2skin

    Einmal editiert, zuletzt von mapovi ()

    Ne andere Idee:


    du könntest aus einer Udev-Regel heraus ein Skript starten, dass dir den nächsten freien Device-Namen zurückgibt. Den setzt du dann über die Regel.


    Grüße,
    Matthias

    Client: Antec Fusion Black, GA-MA78GM-S2H, Athlon X2 4050e, NVidia 9400GT per HDMI an Samsung LCD, Precise, vdr-sxfe, XBMC
    Server: Intel, Trusty, VDR 2.0.2, xineliboutput-plugin, 2x TechnoTrend CT2-4400

    Hi,


    Zitat

    Original von Rincewind99
    du könntest aus einer Udev-Regel heraus ein Skript starten, ...


    das mit den Skripts von Udev aus ausführen, ist manchmal 'n bisschen tricky (Skript entbinden, Ausgaben umlenken, etc.). Hier mal ein Beispiel aus einer meiner rules unter /etc/udev/ruled.d/z98-cryptsetup.rules:

    Code
    ACTION=="add", BUS=="usb", KERNEL=="sd?1", SYSFS{idVendor}=="152d", SYSFS{idProduct}=="2329", SYSFS{serial}=="00000000xxxx", SYMLINK+="fusi1", RUN+="/bin/bash -c '/etc/udev/scripts/automount.sh start fusi1 & >/dev/null </dev/null 2>&1'"

    Viel Erfolg!


    Grüße joker

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 8GB RAM | 120GB SSD System + 3TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P553 | SEDU + 96 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

    Wobei hiermit:

    Code
    ACTION=="add", BUS=="usb", KERNEL=="sd?1", SYSFS{idVendor}=="152d", SYSFS{idProduct}=="2329", SYSFS{serial}=="00000000xxxx", SYMLINK+="fusi1", RUN+="/bin/bash -c '/etc/udev/scripts/automount.sh start fusi1 & >/dev/null </dev/null 2>&1'"

    das Automountskript nach Anlegen des Device ausgeführt wird. Was mapovi braucht ist eher sowas:

    Code
    KERNEL=="ttyUSB*", PROGRAM="findNextName.sh", NAME="%c"

    oder so ähnlich. Das Skript muss halt vor Anlegen des Device ausgeführt werden, sonst macht es keinen Sinn.


    Siehe auch hier: http://reactivated.net/writing…ules.html#external-naming


    Grüße,
    Matthias

    Client: Antec Fusion Black, GA-MA78GM-S2H, Athlon X2 4050e, NVidia 9400GT per HDMI an Samsung LCD, Precise, vdr-sxfe, XBMC
    Server: Intel, Trusty, VDR 2.0.2, xineliboutput-plugin, 2x TechnoTrend CT2-4400

    Einmal editiert, zuletzt von Rincewind99 ()

    Rincewind99


    Aber wie soll so ein Script aussehen, es muss ja ein noch nicht angelegtes Device abfragen? Wenn ich dem Script BUS und DEVICE ID übergebe, könnte man das Device temporär anlegen, aber elegant wäre es dann nicht mehr. Oder das Script könnte alle schon bestehenden Devices prüfen und anhand dessen entscheiden wie es heißen soll. Dabei ist das Problem, dass die Erkennung des USB-Gerätes über den stdout eines Abfragescripts läuft. Das dauert beim 1W 5 Sekunden bis eine sichere Aussage getroffen werden kann ob es das gesuchte Gerät ist (und das in sysinit).
    Gibt es beim Atmolightcontroller eine schnellere Möglichkeit festzustellen, ob er angeschlossen ist?

    2.6.29-gentoo-r5, vdr-1.7.9, xine-vdpau-284, vdr-xine 0.93 - 5050e, M3A78-EM, Postville, 2xTTS21600

    PearlHD text2skin

    Zitat

    Oder das Script könnte alle schon bestehenden Devices prüfen und anhand dessen entscheiden wie es heißen soll.


    Genau so dachte ich mir das. Wenn die Regel nur auf deine beiden PL2303 passt und du individuelle Devicenamen benutzt reicht doch zur Feststellung, ob ein Device existiert, die pure Existenz eines Device-Files. Die werden doch von Udev beim Entfernen des Devices auch wieder gelöscht.


    Ist zugegebenermaßen ein naiver Ansatz - keine Ahnung, ob das so funktionieren könnte. Von Eleganz war sowieso keine Rede :)


    Hast du es eigentlich mal mit PLACE probiert? Aus Udev Man:

    Code
    PLACE
    Match the topological position on bus, like physical port of USB device


    Das sollte doch eigentlich konstant bleiben solange du nicht umstöpselst.

    Client: Antec Fusion Black, GA-MA78GM-S2H, Athlon X2 4050e, NVidia 9400GT per HDMI an Samsung LCD, Precise, vdr-sxfe, XBMC
    Server: Intel, Trusty, VDR 2.0.2, xineliboutput-plugin, 2x TechnoTrend CT2-4400

    Rincewind99


    PLACE ist ja %p. %p gibt folgendes aus:

    Code
    /devices/pci0000:00/0000:00:02.0/usb2/2-3/2-3:1.0/ttyUSB0/tty/ttyUSB0


    Das kann man natürlich nicht als Devicename nutzen, deshalb ein Script findNextName.sh:

    Bash
    #!/bin/sh 
udevadm info --query=all  --name=%1 | grep ID_PATH | cut -d'-' -f 4 | sed 's/:/_/g' | cut -d'.' -f 1


    Und die Udev Regel:

    Code
    SUBSYSTEMS=="usb", ATTRS{idProduct}=="2303", ATTRS{idVendor}=="067b", PROGRAM="/usr/local/bin/findNextName.sh %p", SYMLINK+="ttyUSB_%c"


    Sieht gut aus, funktioniert aber leider nicht.
    Jetzt wird aber erstmal Weihnachten gefeiert. :)

    2.6.29-gentoo-r5, vdr-1.7.9, xine-vdpau-284, vdr-xine 0.93 - 5050e, M3A78-EM, Postville, 2xTTS21600

    PearlHD text2skin

    Was sagt denn eigentlich

    Code
    udevadm info --attribute-walk  --name=ttyUSB0

    Bleiben

    Code
    ATTRS{busnum}=="x"
ATTRS{devnum}=="x"

    denn konstant?


    Ein ruhiges Fest :)


    Matthias

    Client: Antec Fusion Black, GA-MA78GM-S2H, Athlon X2 4050e, NVidia 9400GT per HDMI an Samsung LCD, Precise, vdr-sxfe, XBMC
    Server: Intel, Trusty, VDR 2.0.2, xineliboutput-plugin, 2x TechnoTrend CT2-4400

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden