Forum: PC-Programmierung Wie erkennt man "Re-Enumerierung" des seriellen Ports unter Unix?


von Herbert (Gast)


Lesenswert?

Hier mal wieder ein theoretischer Fall, den ich nicht weiß,
wie man ihn löst:

Ich hab ein Linux-Gerät mit einem seriellen Port via USB (FTDI, oder was 
auch immer, gibt ja zahlreiche Hersteller).
Es bietet einen Port via CDC a la /dev/ttyACM0 (oder was für ein Name 
auch immer) an. Ich öffne den Port und kann Daten austauschen. Also 
funktioniert einwandfrei. Mein Programm läuft und es wird das Gerät 
abgezogen und wieder eingesteckt (oder macht einen Reset, 
Firmware-Update, was auch immer).
D.h. /dev/ttyACM0 wird obsolete (nennt sich dies orphan?) und erscheint 
dann neu als /dev/ttyACM1.
Über welche Weg kann ich dieses Verhalten erkennen?
Bemerke ich etwas auf dem seriellen Port? Bekomme ich dort eindeutige 
Fehler, einen Callback o.ä., so dass ich diese Situation erkennen kann?
Geht es irgendwie übr udev? Oder anderer Weg zum USB?
Vermutlich gibt es auch den Fall, dass ein 2. Gerät anderes angesteckt 
wird, welches ich dann nicht einfach benutzen darf. Also braucht es 
vermutlich noch eine Abfrage der VID, PID und vor allem USB 
Seriennummer?

Hat da jemand Erfahrung? Oder gibt es eine Webseite, ein Tutorial, das 
auf diese Dinge eingeht?

: Verschoben durch Moderator
von MaWin (Gast)


Lesenswert?

Herbert schrieb:
> Über welche Weg kann ich dieses Verhalten erkennen?

udev ADD rule schreiben.

von Arno (Gast)


Lesenswert?

...und ggf. mit einer udev-Regel auf das Abziehen reagieren 
(ACTION=="remove") und ein Signal an dein Programm senden, dass dein 
Programm den Port schließt. Dann kann beim Wiederanstecken auch wieder 
ttyACM0 (oder gleich abhängig von VID/PID ttyMyDevice) angelegt werden.

Denn dass das Gerät beim Wiederanstecken nicht wieder ttyACM0 heißt, 
liegt meist nur daran, dass dein Programm ttyACM0 noch offen hält.

Ich hab udev mit http://reactivated.net/writing_udev_rules.html gelernt. 
Ist allerdings über 10 Jahre alt, und so richtig gepflegt wirkt es 
nicht. Ungefähr zeitgleich mit udev kam auch diese Unsitte auf, 
Dokumentation immer weiter zu verstreuen, z.B. statt Upstream ein 
vernünftiges Howto / Wiki zu erstellen für jede einzelne Distribution 
eins - die je nach Philosophie häufig nur Teile der Information 
enthalten. Plus 100 Blogeinträge "so hab ich meine erste udev-Regel 
geschrieben", damit google auch gar keine Chance mehr hat, tiefgehende 
Infos zu finden, die zunehmend auch nur noch in irgendwelchen 
Blogeinträgen oder Changelogs versteckt werden.</rant>

MfG, Arno

von Olaf (Gast)


Lesenswert?

Hier mal ein Beispiel:

RUN+="/sbin/modprobe usbserial vendor=0x0403 product=0xED72" 
RUN+="/bin/sh -c 'echo 0403 ED72 > 
/sys/bus/usb-serial/drivers/ftdi_sio/new_id'", SYMLINK+="hameg"

Das macht immer den Port "hameg" auf wenn ich mein Oszi anstecke.

Olaf

von Bauform B. (bauformb)


Lesenswert?

Herbert schrieb:
> /dev/ttyACM0 wird obsolete (nennt sich dies orphan?) und erscheint
> dann neu als /dev/ttyACM1.
> Über welche Weg kann ich dieses Verhalten erkennen?
> Bemerke ich etwas auf dem seriellen Port? Bekomme ich dort eindeutige
> Fehler?

Ein read() gibt in dem Fall 0 zurück, also End Of File. Das dürfte bei 
einem tty eindeutig genug sein. Bei anderen groben Fehlern gibt es ja 
die normale -1 plus errno.

Übrigens, auch ganz ohne udev findet man die Seriennummer der 
FTDI-Konverter unter
1
/sys/class/tty/ttyUSBx/device/../../serial
 evt. plus/minus ein paar "../".

von Blechbieger (Gast)


Lesenswert?

Für das Problem der sich ändernden Namen hat dein Linux wahrscheinlich 
schon passende udev rules. Einfach mal in das Verzeichnis 
/dev/serial/by-id reinschauen was da bei anstecken und abziehen 
passiert.

Wie man das aber im Programm handelt wenn das geöffnete Device abgezogen 
und wieder angesteckt wird k.A. Vermutlich schließen, schauen ob es das 
Device in /dev/serial/by-id wieder gibt und neu öffnen.

von gnureiremune-er (Gast)


Lesenswert?

> Hat da jemand Erfahrung? Oder gibt es eine Webseite, ein Tutorial, das
> auf diese Dinge eingeht?

https://www.linux.com/training-tutorials/systemd-services-reacting-change/

sicher udev aber seid schön brav und macht systemD auch glücklich :D

Bitte 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
Noch kein Account? Hier anmelden.