Hi all ,im trying to connect pixhawk with orin nx with FT232R module but i cant find my usb port , actually it finds it with dmesg | grep FT232 command but it does not tell me in what usb port its connected .
I also use commands to find all my tty ports but noone of them are ttyUSB*, any ideas?
Can i connect it with a serial ports avoiding usb ?
Thanks
Serial port naming depends on the driver, which in turn depends on the chipset. You should post the actual log lines from:
dmesg | egrep -i '(usb|uart|serial|ft232|tty)'
You could create a log via:
dmesg | egrep -i '(usb|uart|serial|ft232|tty)' 2>&1 | tee log_grep.txt
If there are other terms you might think useful in the search, just add those in (or remove one if it seems the results are unrelated).
Keep in mind that if the USB side sees the device, then it becomes a question of the driver taking ownership of the device. It is the driver itself which creates and names that file (sometimes renamed via the udev system), so what we’re really looking for (in addition to the name of the file) is what drivers might want the device. It could be that either (A) the driver is not installed, or (B) the name is different.
Incidentally, the naming convention for “/dev/ttyUSB#” is for FTDI brand chipsets. Others might use that as well, but if the chipset is not FTDI, then probably the name would differ.
Even if you don’t connect pixhawk, connecting only the FTDI should show in linux as /dev/ttyUSB*
Are you sure the FT232R is working ?
Try “lsusb” command and see whether the FTDI is being listed once FT232R is connected (send us the output)
Hello guys sorry for the late delay , those are the inputs in txt format:
1st command (10.4 KB)
2st command (10.6 KB)
i still cant understand what USB port i must pass in my dronekit - mavlink programm in order to send data .Any clue ?
Sorry for the late delay , i remember i did it but only said that i have a UART port with FT232R connected .Nothing specific like USB port, i will try it again later and come to you because my client have the hardware right know.
Please let us know the exact model
Is it a dev kit or custom board ?
If there is a micro-usb pot, then connect to it from PC
and check whether /dev/ttyACM0 is created and try to use it.
See whether the below link helps
Which of these log lines are produced as a result of plugging in the device?
[ 32.716035] usb 2-1.4: new SuperSpeed Gen 1 USB device number 3 using tegra-xusb
[ 32.743141] usb 2-1.4: New USB device found, idVendor=8086, idProduct=0b5c, bcdDevice=50.e0
[ 32.743150] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 32.743154] usb 2-1.4: Product: Intel(R) RealSense(TM) Depth Camera 455
[ 32.743158] usb 2-1.4: Manufacturer: Intel(R) RealSense(TM) Depth Camera 455
[ 32.743161] usb 2-1.4: SerialNumber: 221123061353
[ 32.801355] input: Intel(R) RealSense(TM) Depth Ca as /devices/platform/3610000.xhci/usb2/2-1/2-1.4/2-1.4:1.0/input/input24
[ 32.819904] usbcore: registered new interface driver uvcvideo
[ 32.819909] USB Video Class driver (1.1.1)
[ 51.611636] usb 1-2.3: new full-speed USB device number 4 using tegra-xusb
[ 51.725250] usb 1-2.3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
[ 51.725257] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 51.725262] usb 1-2.3: Product: FT232R USB UART
[ 51.725265] usb 1-2.3: Manufacturer: FTDI
[ 51.725268] usb 1-2.3: SerialNumber: A50285BI
[ 51.758431] usbserial: exports duplicate symbol usb_serial_resume (owned by kernel)
Just for reference, vendor ID 0x8086 is Intel (an interesting number to link to Intel since the 8086 was one of Intel’s origins), and 0x0b5c is not listed (which would mean it is a newer product; typically, unless you’ve installed something for udev to recognize this product ID, then no driver could be selected since the existing database does not associate a driver-to-chipset assignment).
The next part with vendor ID 0x0403 is one I would expect. This is vendor FTDI, probably the most well-known UART manufacturer (their UARTs are usually supported by default). That product ID is for “6001 FT232 Serial (UART) IC”. FTDI naming convention is “/dev/ttyUSB#” (where “#” starts at 0). The ttyACM# is a different vendor’s chipset.
Normally the device plugin log would also meantion which ttyUSB# is assigned. What do you see from:
ls -l /dev/ttyUSB*
The part which might be confusing the system, even if everything else is correct, is indicated here:
[ 51.758431] usbserial: exports duplicate symbol usb_serial_resume (owned by kernel)
This sounds like maybe there is a module trying to produce a symbol which already exists in the kernel itself. If the module has different source code, e.g., it is from a patch or has a bug workaround, then one would need to first remove the symbol which is integrated into the kernel in a non-module format. This is something I would not advise doing (it is a lot of work compared to adding a module) unless you know the default version which exists integrated into the kernel has some flaw that the module is intended to work around.
Notice how the ID vendor/product “8086:0b5c” results in this:
[ 32.819904] usbcore: registered new interface driver uvcvideo
The same thing is replaced by the duplicate symbol warning. The module cannot insert because there is already a driver. I don’t see earlier mention of ft232, and so it seems the integrated driver did not find this hardware (or if it did, it did not mention the hardware). Remember how I said that the USB database I looked at did not know what that particular product ID is? It is possible the driver build into the kernel would succeed if it had that ID knowledge (I don’t know for sure that the kernel is using the same table of IDs I am looking at, but probably it is). Perhaps this is what the external module is set up for: To recognize that product ID without consulting an outside table (I don’t know for sure, but it seems likely this is what any patch is for).
Sometimes a patch or a pseudo driver (my term, it isn’t a real term; I’m implying something about picking a driver rather than providing one) will update udev to add an association between an unknown vendor/product ID and a driver. Useful when the driver itself is correct, and the system just doesn’t know this. Or one could edit the driver itself and add this ID combination so the ID database itself does not need this. The latter is useful in some cases, but not really advisable if not needed since the driver might get updated and lose that knowledge.
So I have these questions:
Image and all modules, followed by adding this module (which means the module will then be able to load; there won’t be a duplicate symbol).ls -l /dev/ttyUSB*”? I ask because if a file by that name exists, then maybe the driver integrated into the kernel already created this, and it is equivalent to the ttyACM* file, and just uses a different chipset.This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.