I want to use USB port on Jetson Nano B01 to communicate with other devices ( just like the image above ), but I can’t find anything named “/dev/ttyUSB*”
When I use raspberry Pi, can easily use USB with <wiringPi.h> and <wiringSerial.h>, for example: fd=serialOpen(“/dev/ttyUSB1”,19200) , but you know wiringPi does not work on Jetson.
So, (1):What is the correct path of USB ports (just like “/dev/ttyUSB*”) ?
(2) What is the most commonly used library of Jetson Nano to deal with the USB serial communication? C++ first, python also ok.
As background, all files in “/dev” are actually the result of a driver running in the kernel pretending to be a file, and not a real file. Having a file appear or disappear in “/dev” indicates a driver having loaded or unloaded. Different chipset manufacturers typically use different naming conventions for what appears in “/dev”, and for the most part, a “/dev/ttyUSB#” name is likely an FTDI chipset.
So far as I know the FTDI drivers are there by default. However, what do you see from this command? zcat /proc/config.gz | grep 'FTDI'
If you see this, then the driver is available as a module: CONFIG_USB_SERIAL_FTDI_SIO=m
If the driver is loading, then the driver will show up in command “lsmod”.
To see what type of device you really have, monitor “dmesg --follow”. Then plug in the USB device and see what the log adds for your device. Note that if this is some other chipset, then possibly the issue is just using the wrong naming convention.
Note: For the most part language used in programming is irrelevant, and one would use the device special file in “/dev” as if it is a normal file. At times one would issue an IOCTL command (this supplements normal file writes and offers custom commands to pass through to the driver, e.g., speed setting).
I find that the file “/dev/ttyUSB*” will appeared only when I plug in the USB devices… sorry, it’s my carelessness.
It is interesting because “/dev/ttyTHS1” always exists even I do not use pin8 and pin10 for UART, and on Raspberry Pi, “/dev/ttyUSB*” also always exists .
Now I have used ‘pyserial’ to communicate with other devices by USB port successfully. Thank you very much!
Related trivia: UARTs are not plug-n-play, meaning they cannot self report how to find or use them. This information instead comes from the device tree, and this is how the actual content becomes available in “/dev”. However, using or not using pins of a UART will never change what shows up in “/dev” since the UART cannot tell the operating system that the pins are connected or disconnected.
Normally the “/dev” file would only show up when the driver loads, but in some cases you will see a file which exists even if the driver is not loaded. However, the file won’t work without the driver. Such a file is only a “stub” template. This relates to the “old days” when all files in “/dev” had to have assistance before the driver could work. The command for generating such stub files is from “mknod” (see “man mknod”), but these days this is not needed.
The reason some of those files are still present from mknod is usually because of requirements in the initial ramdisk, prior to some of the infrastructure for dynamically generating this content is available (the initrd is itself its own simplified full operating system used as an “adapter” between running in RAM and running from disk).
