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....