I connected a Ublox gps receiver on a usb connector. It is a standard serial connection. On my Raspberry Pi4 I see a ttyUSB0, which gives me a connection to the GPS receiver. But on my Visionfive V2 comes no ttyUSB* . How can I get a connection to a serial USB device?
1 Like
I have also found this to be the case. The current kernel probably lacks the usb-serial kernel driver.
Have you already tried to communicate with the GPS receiver via I2C? The Raspberry Pi doesn’t get along with the I2C clock stretching of my ZED-F9P, but with the Visionfive V2 I have hope that the I2C clock stretching works.
user@vfive2-8:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 2e8a:f00a Raspberry Pi Pico W
Bus 001 Device 003: ID 1546:01a9 U-Blox AG u-blox GNSS receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
user@vfive2-8:~$ cat /proc/tty/drivers
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
rfcomm /dev/rfcomm 216 0-255 serial
ttyprintk /dev/ttyprintk 5 3 console
sifive-serial /dev/ttySIF 248 0-7 serial
serial /dev/ttyS 4 64-69 serial
hvc /dev/hvc 229 0-7 system
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
pty_slave /dev/ttyp 3 0-255 pty:slave
pty_master /dev/pty 2 0-255 pty:master
unknown /dev/tty 4 1-63 console
@SunWukong,
I get the same results, and lsusb together with lsusb -t shows:
root@starfive:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 046d:c03d Logitech, Inc. M-BT96a Pilot Optical Mouse
Bus 001 Device 004: ID 413c:2113 Dell Computer Corp. KB216 Wired Keyboard
Bus 001 Device 003: ID 090c:1000 Silicon Motion, Inc. - Taiwan (formerly Feiya Technology Corp.) Flash Drive
Bus 001 Device 008: ID 1546:01a7 U-Blox AG [u-blox 7]
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@starfive:~# lsusb -t
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
|__ Port 1: Dev 8, If 0, Class=Communications, Driver=, 12M
|__ Port 1: Dev 8, If 1, Class=CDC Data, Driver=, 12M
|__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 480M
|__ Port 3: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 3: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 4: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
root@starfive:~#
In my case: Port 1 Dev 8 has no driver. Is this driver available at Starfive? If so, we could modprobe it.
Unplug the device.
In a terminal run:
$ sudo dmesg
Plug the USB device in and see what debug information was added when the new device was plugged in. Looking at the last 30 lines it probably enough to see it being plugged in.
$ sudo dmesg | tail -30
Does it give the name of the tty device (possibly something like /dev/ttyACM0 at a guess) or does it give an error message ?
1 Like
Try dmesg -w for realtime output.
2 Likes
My mistake, not to have included a dmsg output. Because there was nothing interesting to see, I forgot to show it here.
[ 1952.814838] usb 1-1.3: new full-speed USB device number 4 using xhci_hcd
^C
user@vfive2-8:~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 2e8a:f00a Raspberry Pi Pico W
Bus 001 Device 004: ID 1546:01a9 U-Blox AG u-blox GNSS receiver
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
You could create your own custom udev rules file (Userspace DEVice manager), which will create a device when your GPS device is plugged into any USB port.
If the OS does not use systemD the default location for udev files is typically /etc/udev/rules.d/
If it does use syetemD then pick between /usr/lib/udev/rules.d/ /usr/local/lib/udev/rules.d/ /lib/udev/rules.d/ depending on your distribution (I’m not a systemD fan, config files should always be under /etc ).
Keep it simple to begin with, try something basic like:
$ cat /etc/udev/rules.d/90-mygps
# u-blox AG, u-blox 7 [linux module: cdc_acm]
ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a7", SYMLINK+="gps%n" MODE="0666"
# u-blox AG, u-blox 9 [linux module: cdc_acm]
ATTRS{idVendor}=="1546", ATTRS{idProduct}=="01a9", SYMLINK+="gps%n" MODE="0666"
EDIT: You could probably install the u-blox ubxlib and then copy and modify the comment and two lines from u-blox for something a bit more complex.
Another possible reason why ttyUSB isn’t present, although the above is more likely in this particular case, is Linux braidamage where it installs a Braille TTY manager that prevents other USB devices from being created by capturing all USB->serial device IDs. To fix this, you need to remove the driver:
sudo apt remove brltty
however it will get reinstalled again at the next OS update/upgrade. To permanently fix it:
systemctl list-units | grep brltty
systemctl mask brltty-udev.service
systemctl stop brltty-udev.service
This problem, and the fix, applies to any Linux install, not just the VF2 one.
2 Likes
On x86 Ubuntu, apt purge brltty works and won’t get reinstalled. Not sure applicable on other distro.
Maybe not enabled buliding in current kernel…
user@vfive2-8:~$ sudo apt remove brltty
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Package 'brltty' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Yes, it looks like that.
After having it come back from the dead like some zombie horror movie, to bite me again after I’d fixed it, I went for the nuke-it-from-orbit approach :-). However as others have pointed out, it’s not present (yet!) in the current build so it won’t be the problem in this case.
removing and installing the gps device gives nothing special in dmesg:
[592778.197637] usb 1-1.1: USB disconnect, device number 8
[592788.477572] usb 1-1.1: new full-speed USB device number 9 using xhci_hcd
[593109.493560] usb 1-1.1: USB disconnect, device number 9
[593121.051937] usb 1-1.1: new full-speed USB device number 10 using xhci_hcd
So now I will try the udev rules of @mzs
If there is no kernel module, check with:
$ ls -l /lib/modules/`uname -r`/kernel/drivers/usb/class/cdc-acm.ko
Another option might be to use the generic serial driver.
e.g.
$ sudo /bin/bash
# echo 1546 01a7 >/sys/bus/usb-serial/drivers/generic/new_id
# insmod usbserial vendor=0x1546 product=0x01a7
# exit
$
But it does require that there is a generic usb serial driver module, check with:
$ ls -l /lib/modules/`uname -r`/kernel/drivers/usb/serial/usbserial.ko
or
$ zgrep "CONFIG_USB_SERIAL=" /proc/config.gz
you should build a new kernel with enabling the below configures at least,
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
I just test my usb FDTI dongle based on the following configs. it works.
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_FTDI_SIO=y
4 Likes