J'utilise Ubuntu 18.10 x64 sur mon ordinateur portable et 17.10 x64 sur une autre machine. Les informations ci-dessous proviennent de l'ordinateur portable 18.10, mais les deux ont le même problème.
J'ai attaché une carte USB à série (un clone chinois TI SmartRF04EB, utilisant un équivalent à un MCU Silicon Labs C8051F320 pour fournir une interface USB) câblé à une carte de développement Chipcon 8051 mais/dev/ttyUSB0 etc. n'est pas créé qui J'ai besoin d'émettre des commandes de débogage sur la carte, par exemple sur un terminal moserial.
Pouvez-vous suggérer pourquoi l'entrée/dev/ttyUSB n'est pas créée automatiquement et comment puis-je m'assurer qu'elle l'est?
Merci d'avance.
Contexte
Je peux me connecter à partir d'un Windows VM dans VirtualBox et lire les registres sur la carte de développement, mais pas à partir de ma machine hôte. Le périphérique Chipcon est la carte adaptateur USB-série, car j'obtiens la même chose résultats si la carte de développement 8051 est déconnectée.
MacBookPro:~$ lsusb
Bus 001 Device 012: ID 11a0:eb20 Chipcon AS
Dmesg montre que l'appareil est reconnu:
MacBookPro:~$ dmesg | grep 1-1.1:
[ 1989.355072] usb 1-1.1: new full-speed USB device number 12 using xhci_hcd
[ 1989.468502] usb 1-1.1: New USB device found, idVendor=11a0, idProduct=eb20, bcdDevice= 0.50
[ 1989.468505] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1989.468506] usb 1-1.1: Product: SmartRF04EB
[ 1989.468508] usb 1-1.1: Manufacturer: Chipcon AS
[ 2006.115847] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 2036.516953] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 2058.765773] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 2105.307403] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[ 4370.664093] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
[64333.681207] usb 1-1.1: reset full-speed USB device number 12 using xhci_hcd
Mais il n'y a pas d'entrée/dev/ttyUSB, ou toute autre entrée immédiatement sous/dev/ou/dev/usb /:
MacBookPro:~$ ls /dev/ttyUSB*
ls: cannot access '/dev/ttyUSB*': No such file or directory
Une entrée est créée dans/dev/vboxusb/001/012 lorsque le périphérique est branché, ce qui permet à Windows VM de communiquer avec le périphérique. Le numéro change lorsqu'il est reconnecté, mais ne fonctionne pas) t affecter la VM.
Le pilote est répertorié par les périphériques USB comme Aucun:
MacBookPro:~$ usb-devices
...
T: Bus=01 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 12 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=11a0 ProdID=eb20 Rev=00.50
S: Manufacturer=Chipcon AS
S: Product=SmartRF04EB
C: #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
Une simple règle Udev, suggérée ailleurs, ne fait aucune différence:
MacBookPro:~$ cat /etc/udev/rules.d/99-usb-serial.rules
# SmartRF05 Evaluation Board
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a0", MODE="0666"
# SmartRF04 Evaluation Board
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="11a0", ATTRS{idProduct}=="db20", MODE="0666"
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="11a0", ATTRS{idProduct}=="eb20", MODE="0666"
# CC Debugger
ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0451", ATTRS{idProduct}=="16a2", MODE="0666"
Je me suis ajouté aux groupes tty et dialout, sans effet.
Exécuter udevadm:
MacBookPro:~$ Sudo udevadm test -a -p $(udevadm info -a udevadm info -q path -n /dev/bus/usb/001/012)
calling: test
version 239
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
Load module index
Parsed configuration file /lib/systemd/network/99-default.link
Created link configuration context.
Reading rules file: /lib/udev/rules.d/39-usbmuxd.rules
...
Reading rules file: /lib/udev/rules.d/99-systemd.rules
rules contain 393216 bytes tokens (32768 * 12 bytes), 40208 bytes strings
32422 strings (271011 bytes), 28868 de-duplicated (234358 bytes), 3555 trie nodes used
IMPORT builtin 'usb_id' /lib/udev/rules.d/50-udev-default.rules:13
IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:13
handling device node '/dev/bus/usb/001/012', devnum=c189:11, mode=0600, uid=0, gid=0
preserve already existing symlink '/dev/char/189:11' to '../bus/usb/001/012'
ACTION=-p
BUSNUM=001
DEVNAME=/dev/bus/usb/001/012
DEVNUM=012
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.1
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=SmartRF04EB
ID_MODEL_ENC=SmartRF04EB
ID_MODEL_ID=eb20
ID_REVISION=0050
ID_SERIAL=Chipcon_AS_SmartRF04EB
ID_USB_INTERFACES=:ffffff:
ID_VENDOR=Chipcon_AS
ID_VENDOR_ENC=Chipcon\x20AS
ID_VENDOR_FROM_DATABASE=Chipcon AS
ID_VENDOR_ID=11a0
MAJOR=189
MINOR=11
PRODUCT=11a0/eb20/50
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=1989348663
Unload module index
Unloaded link configuration context.
L'entrée USB à la ligne 13 de /lib/udev/rules.d/50-udev-default.rules:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb --subsystem=usb"
ENV{MODALIAS}!="", IMPORT{builtin}="hwdb --subsystem=$env{SUBSYSTEM}"
ACTION!="add", GOTO="default_end"
Trois changements ont résolu le problème:
Rebranchement du câble JTAG. Pour une raison quelconque, la connexion semblait avoir été défectueuse, car cc-tool a alors reconnu la carte de développement.
Modification de la 6ème ligne de la règle udev avec l'ajout d'un lien symbolique à ttyUSB0 pour lire:
ACTION == "add", SOUS-SYSTÈME == "usb", ATTRS {idVendor} == "11a0", ATTRS {idProduct} == "eb20", MODE = "0666", SYMLINK = "ttyUSB0"
déclencheur udevadm
udevadm control --reload-rules