Hallo, Ich habe folgendes Problem. Eine Relaisplatine hängt am Usb Port (über FTDI Serial) => /dev/ttyUSB0 Nun kommt es vor, dass (elektromagnetische einstreuung oder was weis ich, an dem Problem arbeite ich gerade, es passiert halt einfach) sich der FTDI Port kurz abmeldet. Daraufhin bemerkt (udev nehme ich an) dass der Port disconnected ist, und macht ein ReMapping. Da zu diesem Zeitpunkt der Port /dev/ttyUSB0 belegt ist macht udev (oder ftdi?) das mapping auf den nächsten freien Port => /dev/ttyUSB1 Das führt dazu, dass mein Programm die Schnittstelle nicht mehr finden kann. Was absolut nicht wünschenswert ist. Wie bekomme ich nun udev , oder ftdi dazu, dass ein bestimmtes USB Gerät (der FTDI chip) Immer und NUR auf einem bestimmten Port gemapped wird /dev/ttyUSB0 Wenn es nicht verfügbar ist, dann soll es lieber gar nicht gemapped werden, dann kann ich das im Programm festlegen, dass ein Fehler ausgegeben wird. Sobald es jedoch verfügbar ist soll es NUR unter USB0 dran hängen Es gibt vielleicht mit in /etc/udev/ bestimmte möglichkeiten. Doch sind in den existierenden Files nur beispiele für USB Festplatten. Doch wie sage ich dem udev, dass ein bestimmtes ttyUSB Gerät mit einer bestimmten ID auf einen Port soll ? Und wie finde ich die ID (gibt es sowas wie Ne USB MAC Adresse) eines gerätes heraus /dev/proc steht nichts drin) Fals jemand eine Antwort weis, das würde sehr weiter helfen, Google weis nicht wirklich viel über Udev und ttyUSBs
Du könntest dir einen eigenen Link erstellen, in Abhängigkeit von spezifischen Prametern deines USB-Gerätes, wie z.B. Seriennummer. Hier ist mal ein Beispiel das ich für ein GPS-Empfänger nehme, der dann als /dev/rgm3800 erscheint: SUBSYSTEMS=="usb", DRIVERS=="pl2303", SYMLINK+="rgm3800", MODE="666" Die Zeile habe ich in die Datei: 10-local.rules unter /etc/udev/rules.d abgelegt. Die oben gezeigt Regel wird durch den Treiber "pl2303" aktiviert. Unter dem folgenden Link findest du eine Beschreibung wie man die udev-Regel erzeugt und auch wie man herausfindet welche Parameter man in die Regel schreiben soll: http://reactivated.net/writing_udev_rules.html
hi, danke Günter, das hat geholfen
für alle die es interessiert wie das geht.
1. herausfinden der serial des ftdi devices
> lsusb -v
Zeigt alle Geräte infos, unter Device Descriptor steht die iSerial des
Devices, damit ist ein Device EINDEUTIG definiert
iSerial 3 A6006cWd
2. Neue udev Regel erstellen
File erstellen: /etc/udev/rules.d/10-local.rules
SYSFS{idProduct}=="6001",SYSFS{idVendor}=="0403",SYSFS{serial}=="SERIAL"
,SYMLINK+="SYMNAME"
unter SERIAL kommt die Serial die oben herausgefunden wurde
unter SYMNAME der Name unter dem man es in dev gemaped haben möchte
3. */dev/SYMNAME*
unter diesem link ist das serialinterface nun ansprechbar, da jetzt die
Serial des Devices angegeben wurde, müsste udev dieses Interface IMMER
unter dem gleichen Namen mappen.
[Stänkermodus] Puh, ein Glück, dass das unter Windows von ganz alleine ohne jeglichen Nutzereingriff klappt. Jetzt krieg ich bestimmt wieder Haue :) [/Stänkermodus] duck und weg
@ Supachris <anti OS bashing Modus> Hihi :) Ein Glück dass ich nichts mit den anderen Problemen zu tun habe die sonst auftauchen würden, wenn ich Windows hätte und das kleine Problem sich so einfach lösen lässt *g </anti OS bashing Modus> PS. Mein OS passt auf ein Embded Device, verbraucht 8 Watt an Energie, ist so Gross wie eine NSLU2 eben ist, ist in einer der besten Programmiersprachen (python) Programmierbar, und kann doch alles an Steuerung, was dein Grosses Windows kann ;-) Und Bildschirm und so kram braucht man nicht, das ding liegt (oder steht) in der Ecke und macht was es soll, nämlich steuern und nebenher noch jede menge anderes... PPS: Keine Haue, (jeder benutzt das was er will) nur Mitgefühl, wegen der menge an (anderer) Probleme mit Windows *g
Hihi, ich benutze hier auch Linux, aber nur da, wo es für mich Sinn macht (Heim-Server). Dein Mitgefühl brauch ich nicht mal. Mein Vista macht keine Probleme hier. Weder kleine noch große. P.S.: Ist doch alles nur Spaß :)
:) benutze ja auch nur da Linux , wo es sinn macht (Server), und sonst das Vista Orginal MAC OSX ;-) finds ja auch immer Lustig, ich kenn die heftigen bashings über die versch. OS sei gegrüsst
Naja, man darf halt nich alles pauschalisieren. Zurück zum Thema. Da das bei Windows schon seit mindestens Win2K Standard ist, wundert es mich echt, dass Linux das nicht von Haus aus können soll. Schon seltsam. Andere Frage ist, wieso der sich überhaupt ab- und wieder anmeldet, das hatte ich noch nie, die FTDI funktionieren sehr zuverlässig, ganz im Gegensatz zu Prolific beispielsweise.
@ pauschalisieren -> Jo der Meinung bin ich auch. Ich mein zum spielen ist Win ja auch okey ;-) @ FTDI: An, abmeldet. Das tut der Normal auch nicht, und ist SEHR stabil. So etwas habe ich bisher auch nur aus dem Lehrbuch gehabt, und jetzt das erste mal dass ich damit konfrontiert werde. Ich habe mehrere Pumpen, und einen Schütz, den ich mit den Relais schalte. Bei manchen Konstelationen (und ich habe schon RC-Glieder drin) ist da irgendein EM Feld, was zurück streut in die Relaisplatine. Wenn das vor kommt, sieht es so aus, als ob Kurzzeitig der FTDI Chip ausser Funktion gesetzt ist. (so als ob man den USB Stecker abzieht). Was dann passiert steht schon oben in der Erklärung. der Udev (Zuständig für Hotplug bei Linux) denkt, dass das DEvice ausgestöpselt ist. Danach wird es neu Gemapped, es ist ja nur ganz kurz der Impuls. Jetzt ist aber der Alte Port, auf dem es gemapped wurde noch nicht wieder freigegeben. Daher wird es auf nem neuen Port gemapped (...) Vielleicht könnte man das Problem auch lösen, indem man irgendwo Kondensatoren mit einbaut, die die Störeinstreuung verhindern. Ich bin schon dabei überall RC Glieder rein zu machen. Doch da das Problem nur in bestimmten Schaltkonstelationen auftritt. (Wenn man alle Geräte einzeln schaltet passiert nichts) ist es sehr schwierig die übeltäter Konstelation zu finden. Ausserdem musste ich das ganze sowieso statisch machen, da darüber wichtige Dinge geschaltet werden und auch Notabschaltungen gewährleistet sein müssen muss ichi zuverlässig wissen, dass die Relais immer ansprechbar sind, auch wen was neu gemapped wird....
@Xd Xdxd: Ich nehme an, du kennst dieses Dokument schon: http://www.ti.com/sc/docs/apps/msp/intrface/usb/emitest.pdf Wenn nicht: Da stehen ein paar gute Tipps drin, die man bei der Entwicklung von USB-Schaltungen eigentlich immer beachten sollte, beim Einsatz in gestörten Umgebungen aber ganz besonders.
Vielen Dank für den klugen Tipp mit der Serial-No. in Zusammenhang mit udev! Hat mir sehr geholfen!! Denn ansonsten gibt es zu diesem Thema recht wenig!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.