Eu tenho um Arduino que às vezes fica vinculado a /dev/ttyUSB0 e outras vezes a /dev/ttyUSB1 , fazendo com que meu script falhe.
Eu não quero enumerar todas as possibilidades de onde meu dispositivo poderia estar, mas prefiro que ele esteja vinculado em algum lugar estático, por exemplo, /dev/arduino .
Como faço para isso?
Como sugerido, você pode adicionar algumas regras do udev. Eu editei o /etc/udev/rules.d/10-local.rules para conter:
ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="my_uart"
Você pode verificar as variáveis do seu dispositivo executando
udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0)
Há um guia mais detalhado que você pode ler no link
A sintaxe da regra acima pode funcionar em algumas distribuições, mas não funcionou na minha (Raspbian). Desde que eu nunca encontrei um único documento que explique todos os meandros, eu escrevi o meu próprio, para ser encontrado aqui . Isso é o que se resume a isso.
1. descobrir o que está no ttyUSB:
dmesg | grep ttyUSB
2. listar todos os atributos do dispositivo:
udevadm info --name=/dev/ttyUSBx --attribute-walk
(com o (s) número (s) do seu aparelho em vez de x, é claro). Escolha um conjunto de identificadores exclusivo, por exemplo, idVendor + idProduct. Você também pode precisar do SerialNumber se tiver mais de um dispositivo com o mesmo idVendor e idProduct. SerialNumbers deve ser exclusivo para cada dispositivo.
3. Crie um arquivo /etc/udev/rules.d/99-usb-serial.rules com algo parecido com esta linha:
SUBSYSTEM=="tty", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678", SYMLINK+="your_device_name"
(supondo que você não precisa de um número de série e, claro, com os números de idVendor e idProduct que você encontrou na etapa 2). 4. Carregue a nova regra:
sudo udevadm trigger
5. Verifique o que aconteceu:
ls -l /dev/your_device_name
mostrará para qual número ttyUSB o link simbólico foi usado. Se for /dev/ttyUSB1 , verifique quem é o proprietário e a que grupo pertence:
ls -l /dev/ttyUSB1
Então, só por diversão:
udevadm test -a -p $(udevadm info -q path -n /dev/your_device_name)
Eu tenho um Rasperry Pi com quatro câmeras. Eu tiro pix com fswebcam , que identifica as câmeras como /dev/video0 .. video3 . Às vezes, a câmera é video0 , vide02 , video4 e video6 , mas podemos esquecer isso por enquanto.
Eu preciso de um ID persistente para identificar um número de câmera, por exemplo, video0 é sempre a mesma câmera porque eu lego as imagens. Infelizmente isso não acontece de forma confiável - na inicialização, as câmeras são enumeradas como video0 .. video3 , mas nem sempre da mesma maneira.
Todas as câmeras têm o mesmo ID e número de série.
A solução para este problema envolve regras do udev, mas também há muitos anzóis.
Se você emitir o comando
udevadm info –attribute-walk –path=/dev/video0
você obtém uma mesa de saída, mas os bits salientes são
KERNEL=”video0”, SUBSYSTEM=”video4linux” and KERNELS=”1:1.2.4:1.0”.
O bit KERNELS é uma porta de hub USB. Com quatro câmeras, há quatro delas - elas não mudam na reinicialização, mas o video{x} associado a uma porta pode mudar.
Portanto, precisamos de uma regra do udev para vincular um número de vídeo a uma porta de hub USB - algo como:
KERNEL==”video0”,SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0”,SYMLINK+=”camera0”
Parece simples - acesse a câmera com
fswebcam –d $realpath /dev/camera0
Exceto que não funciona - se você colocar isso em uma regra do udev e o sistema tiver alocado o vídeo0 (durante a inicialização) para uma porta diferente, a regra do udev será ignorada. O link simbólico para /dev/camera0 diz basicamente no such device . Quadrado um.
O que queremos é vincular um link simbólico a um endereço de hub USB, não um video{x} number. Demorou um programa em Python.
O primeiro passo foi correr
fswebcam –d /dev/video${x} tst.jpg
para x entre 1 e 8. A existência de tst.jpg após cada chamada identifica se há uma câmera neste número de vídeo. A partir disso, faça uma lista de números de vídeo ativos. Minha experiência tem sido que é 0,1,2,3 ou 0,2,4,6 para câmeras que usei.
Outros podem, é claro, criar essa lista usando um processo diferente.
Em seguida, para cada número de vídeo na lista, execute
udevadm info –attribute-walk –path=/dev/videox > dd
e extraia o KERNELS= line de dd . Deste processo você acaba com uma lista de endereços de porta USB para as câmeras. Classifique essa lista para que, na próxima etapa, você sempre a processe na mesma ordem. Chame isso de "lista de endereços".
Execute novamente a coisa udevadm … > dd e faça uma lista parecida com
KERNEL==”video0”, SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0 ”,SYMLINK+=”camerax”. Call this the “video list”.
Agora, percorra a lista de endereços. Para cada entrada, localize a entrada correspondente na lista de vídeos. Crie uma nova lista que se parece com uma coleção de linhas como
KERNEL==”video0”, SUBSYSTEM=”video4linux”,KERNELS==”1:1.2.4:1.0 ”,SYMLINK+=”camera2”
O x (número do link simbólico) é substituído pelo número de sequência na lista de endereços.
Agora você tem uma regra do udev que funciona. Um link simbólico vinculado a um endereço de hub USB, independentemente do número de vídeo alocado a essa porta na inicialização.
Escreva a lista final em um arquivo /etc/udev/rules.d/cam.rules . Execute udevadm trigger para ativá-lo e o trabalho está concluído. /dev/camera2 será a mesma câmera (porta USB), independentemente do seu número de vídeo.
Também consegui encontrar um dispositivo exclusivo em /dev/serial/by-id . Ainda não tentei uma reinicialização, mas os arquivos nesse diretório eram apenas links para o arquivo de dispositivo apropriado ( ttyACM[0-9] ). '
Estou executando o arch linux no Raspberry Pi, mas deparei com eles apenas fazendo um find para nomes de arquivos contendo "Arduino". Meus programas python rodam bem usando esses arquivos como dispositivos para ler / gravar dados de / para meus Arduinos (até agora, dois em um único Pi).
Só para dizer que o acima funcionou para mim e também montou automaticamente o dispositivo para mim depois que eu coloquei uma entrada em / etc / fstab (e também chama umount após a remoção do stick)
ou seja,
/ 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"
Então, depois de inserir meu stick USB, recebo:
root:# mount | grep sd
/dev/sda1 on /vol/backup type ext4 (rw,relatime,errors=remount-ro,data=ordered)
Tags usb serial-port arduino linux arch-linux