Anexando dispositivo USB-Serial com PID personalizado para ttyUSB0 em embedded

18

Estou tentando obter um dispositivo FTDI USB-Serial com um PID personalizado para anexar automaticamente (ou mesmo manualmente) a ttyUSB% n, sem muito sucesso. O VID / PID normal do dispositivo é 0403/6001. Quando programado dessa maneira, ele funciona perfeitamente e se conecta automaticamente ao ttyUSB0 quando conectado. Mesmo com o driver recompilado para respeitar nosso novo PID, quando programado com o personalizado ttyUSB0 não aparece, mas o reconhece como um dispositivo ftdi_sio e carrega o driver.

Eu adicionei nosso PID ao cabeçalho e à fonte:

// in ftdi_sio_ids.h
#define FTDI_CUSTOM_PID 0xABCD // not the actual pid
// then in ftdi_sio.c
static struct usb_device_id id_table_combined [] = {
    // devices....
    { USB_DEVICE(FTDI_VID, FTDI_CUSTOM_PID) },
    // ....

Recompilou o kernel inteiro e reformulou o dispositivo. Quando eu conecto o dispositivo, recebo:

usb 1-1: new full-speed USB device number 2 using at91_ohci
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

O lsusb mostra o VID / PID personalizado correto. O driver parece reconhecer que ele deve usar o ftdi_sio com ele, mas não o anexa ao ttyUSB0 como faria com o PID não modificado. Alguma sugestão sobre o que estou fazendo errado aqui?

    
por trycatch 14.03.2013 / 16:35

3 respostas

16

Você não precisa modificar o kernel para apenas uma vez; você pode sobrescrevê-lo.

  1. Desconecte o dispositivo
  2. modprobe ftdi_sio
  3. echo 0403 6001 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
  4. Conecte o dispositivo

E o seu dispositivo deve funcionar.

Sua outra alternativa é usar a interface bind sysfs; Sugiro usar lsusb -t para descobrir o caminho + interface correto nesse caso.

Usando um exemplo parcial do meu sistema, de um dispositivo de armazenamento usb (seria muito similar para serial usb).

$ lsusb -t
...
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/3p, 5000M
        |__ Port 3: Dev 6, If 0, Class=Hub, Driver=hub/3p, 5000M
            |__ Port 3: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
 ...
 $ echo '4-1.3.3:1.0' >/sys/bus/usb/drivers/usb-storage/bind

O formato do número é: BUS-PORT(.PORT)+:1.INTERFACE . O único número que não é visível na saída do lsusb é o primeiro dígito após os dois pontos; e sempre foi um 1 na minha experiência. Alguém com um conhecimento mais profundo do kernel provavelmente pode me dizer o que é e fornecer um contra-exemplo.

    
por 08.12.2013 / 02:19
12

Você não precisa modificar o kernel, você pode automatizar o processo assim:

  1. Adicione a seguinte linha única a /etc/udev/rules.d/99-ftdi.rules

    ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", RUN+="/sbin/modprobe ftdi_sio" RUN+="/bin/sh -c 'echo 0403 6001 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"

  2. Reinicie ou execute sudo udevadm control --reload para escolher a nova regra.

  3. Desconecte o dispositivo.

  4. Conecte o dispositivo.

por 04.11.2014 / 07:25
1

situação absolutamente semelhante aconteceu com a placa eval da SiLabs - o chip USB-UART CP2102 sendo fornecido com VID / PID irregular:

lsusb

Bus 001 Device 002: ID 10c4:804c Cygnal Integrated Products, Inc.

problema resolvido carregando o módulo cp210x e enviando o VID / PID como mencionado antes:

sudo modprobe cp210x

sudo -s

echo 10c4 804c > /sys/bus/usb-serial/drivers/cp210x/new_id

O arquivo 99-cp210.rules correspondente para o udev é o seguinte:

ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="804c", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 804c > /sys/bus/usb-serial/drivers/cp210x/new_id'"

    
por 20.03.2018 / 15:01