Ho un Arduino che a volte viene associato /dev/ttyUSB0e altre volte /dev/ttyUSB1, facendo fallire la mia sceneggiatura.

Non voglio elencare tutte le possibilità di dove potrebbe essere il mio dispositivo, ma preferirei che fosse legato da qualche parte statico, ad es /dev/arduino.

Come ci riesco?

Come suggerito, puoi aggiungere alcune regole udev. Ho modificato il /etc/udev/rules.d/10-local.rulesper contenere:

ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="my_uart"

Puoi verificare le variabili del tuo dispositivo eseguendo

udevadm info -a -p  $(udevadm info -q path -n /dev/ttyUSB0)

C'è una guida più approfondita che puoi leggere su http://www.reactivated.net/writing_udev_rules.html

La sintassi della regola sopra potrebbe funzionare su alcune distribuzioni, ma non sulla mia (Raspbian). Dal momento che non ho mai trovato un unico documento che spiega tutti i dettagli, ho scritto il mio, si trovano qui . Questo è ciò a cui si riduce.
1. scopri cosa c'è su ttyUSB:

dmesg | grep ttyUSB  

2. elenca tutti gli attributi del dispositivo:

udevadm info --name=/dev/ttyUSBx --attribute-walk

(ovviamente con il / i numero / i del tuo dispositivo anziché con x). Scegli un set di identificatori univoci, ad esempio idVendor + idProduct. Potresti anche aver bisogno di SerialNumber se hai più di un dispositivo con lo stesso idVendor e idProduct. I numeri di serie devono essere univoci per ciascun dispositivo.
3. Crea un file /etc/udev/rules.d/99-usb-serial.rulescon qualcosa come questa linea al suo interno:

SUBSYSTEM=="tty", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", SYMLINK+="your_device_name" 

(supponendo che non sia necessario un numero seriale lì, e ovviamente con i numeri per idVendor e idProduct che hai trovato nel passaggio 2.
4. Carica la nuova regola:

sudo udevadm trigger

5. Verifica cosa è successo:

ls -l /dev/your_device_name  

mostrerà a quale numero ttyUSB è andato il link simbolico. Se è /dev/ttyUSB1, quindi verificare che possiede quel ea quale gruppo appartiene:

ls -l /dev/ttyUSB1   

Quindi solo per divertimento:

udevadm test -a -p  $(udevadm info -q path -n /dev/your_device_name)

Il problema con più dispositivi USB identici

Ho un Rasperry Pi con quattro telecamere. Prendo pix con fswebcamche individua le telecamere come /dev/video0.. video3. A volte la fotocamera è video0, vide02, video4e video6ma possiamo dimenticare che per ora.

Ho bisogno di un ID persistente per identificare un numero di telecamera in modo che, ad esempio, video0sia sempre la stessa telecamera perché inserisco le didascalie delle immagini. Sfortunatamente questo non accade in modo affidabile: all'avvio, le telecamere vengono elencate come video0.. video3ma non sempre allo stesso modo.

Tutte le telecamere hanno lo stesso ID e numero di serie.

La soluzione a questo problema riguarda le regole di udev, ma ci sono anche molti ami.

Se si emette il comando

udevadm info –attribute-walk –path=/dev/video0

ottieni un massetto di output ma i bit salienti lo sono

KERNEL=”video0”, SUBSYSTEM=”video4linux” and KERNELS=”1:1.2.4:1.0”.

Il bit KERNELS è una porta hub USB. Con quattro telecamere ce ne sono quattro: non cambiano al riavvio, ma le video{x}porte associate possono cambiare.

Quindi abbiamo bisogno di una regola udev per legare un numero video a una porta hub USB - qualcosa del tipo:

KERNEL==”video0”,SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0”,SYMLINK+=”camera0” 

Sembra semplice: accedi alla videocamera con

fswebcam –d  $realpath /dev/camera0

Tranne che non funziona: se lo inserisci in una regola udev e il sistema ha allocato video0 (all'avvio) su una porta diversa, la regola udev viene ignorata. Il link simbolico /dev/camera0dice sostanzialmente no such device. Square one.

Ciò che vogliamo è associare un collegamento simbolico a un indirizzo hub USB, non a un video{x}numero. Ci è voluto un programma Python.

Il primo passo è stato correre

fswebcam –d /dev/video${x}  tst.jpg

per xtra 1 e 8. L'esistenza di tst.jpgdopo ogni chiamata identifica se v'è una fotocamera a questo numero video. Da questo crea un elenco di numeri di video attivi. La mia esperienza è stata che è 0,1,2,3o 0,2,4,6per le fotocamere che ho usato.

Altri possono ovviamente compilare questo elenco usando un processo diverso.

Quindi, per ogni numero di video nell'elenco eseguire

udevadm info –attribute-walk –path=/dev/videox > dd

ed estrarre il KERNELS= lineda dd. Da questo processo si finisce con un elenco degli indirizzi delle porte USB per le telecamere. Ordina questo elenco in modo che al passaggio successivo, lo elabori sempre nello stesso ordine. Chiamalo "elenco indirizzi".

Esegui di udevadm … > ddnuovo la cosa e crea un elenco simile

KERNEL==”video0”, SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0 ”,SYMLINK+=”camerax”. Call this the “video list”.

Ora passa attraverso l'elenco degli indirizzi - per ogni voce trova la voce corrispondente dall'elenco dei video. Crea un nuovo elenco che assomigli a una raccolta di linee simili

KERNEL==”video0”, SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0 ”,SYMLINK+=”camera2”

La x (numero del collegamento simbolico) è sostituita dal numero di sequenza nell'elenco indirizzi.

Ora hai una regola udev che funziona. Un collegamento simbolico collegato a un indirizzo hub USB, indipendentemente dal numero di video assegnato a quella porta all'avvio.

Scrivi l'elenco finale in un file /etc/udev/rules.d/cam.rules. Esegui udevadm triggerper attivarlo e il lavoro è fatto. /dev/camera2sarà la stessa fotocamera (porta USB) indipendentemente dal suo numero video.

Sono stato anche in grado di trovare un dispositivo unico in /dev/serial/by-id. Non ho ancora provato a riavviare, ma i file in quella directory erano solo collegamenti al file del dispositivo appropriato ( ttyACM[0-9]) .`

Sto eseguendo arch linux su Raspberry Pi, ma mi sono imbattuto in loro semplicemente facendo un findnome file per "Arduino". I miei programmi Python funzionano bene usando quei file come dispositivi per leggere / scrivere dati su / dai miei Arduinos (finora, due su un singolo Pi).

Solo per dire che quanto sopra ha funzionato per me e ha anche montato automaticamente il dispositivo per me dopo aver inserito una voce in / etc / fstab (e chiama anche umount dopo la rimozione dello stick)

vale a dire

/ Etc / fstab

# See /etc/udev/rules.d/5-usb-disk.rules
/dev/backup     /vol/backup     ext4    defaults,errors=remount-ro 0       1

cat /etc/udev/rules.d/5-usb-stick.rules

#
# the next line creates a symlink to this disk drive called /dev/backup 
# i.e.
#   root:# ls -la /dev/backup 
#   lrwxrwxrwx 1 root root 3 Jul 22 19:33 /dev/backup -> sg0

# Backup usb stick - create /dev/backup
# ATTRS{model}=="Cruzer Blade    "
ACTION=="add", ATTRS{model}=="Cruzer Blade    ", SYMLINK+="backup"

# Clean up after removal  
ACTION=="remove", ATTRS{model}=="Cruzer Blade    ", RUN+="/bin/umount /vol/backup"

Quindi dopo aver inserito la mia chiavetta USB ottengo:

root:# mount | grep sd
/dev/sda1 on /vol/backup type ext4 (rw,relatime,errors=remount-ro,data=ordered)