Open MarkJeronimus opened 6 months ago
Extra information:
arnoud@confucius:/home$ lsusb
Bus 004 Device 022: ID 13fe:6300 Kingston Technology Company Inc. SP Mobile C31 (64GB)
Bus 004 Device 014: ID 0424:5734 Microchip Technology, Inc. (formerly SMSC) USB5734
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 037: ID 0424:274c Microchip Technology, Inc. (formerly SMSC) Hub Controller
Bus 003 Device 042: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 003 Device 036: ID 0424:2734 Microchip Technology, Inc. (formerly SMSC) USB2734
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 009: ID 0424:5734 Microchip Technology, Inc. (formerly SMSC) USB5734
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 020: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 032: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 030: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 004: ID 13d3:3414 IMC Networks Bluetooth Radio
Bus 001 Device 029: ID 0424:274c Microchip Technology, Inc. (formerly SMSC) Hub Controller
Bus 001 Device 028: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 027: ID 0424:2734 Microchip Technology, Inc. (formerly SMSC) USB2734
Bus 001 Device 002: ID 13fd:1340 Initio Corporation Hi-Speed USB to SATA Bridge
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
You are comparing two different things. In 2.7, there was no way to retrieve manufacturer information, and in 2.11, the "Unknown" tag for the new manufacturer field just means that the manufacturer details are unable to be identified from standard/sysfs/devfs locations. The thing that's missing from 2.11 that was present in 2.7 was that, in 2.7, the enumeration logic was very convoluted and much more brittle, so one methodology for testing for USB-based serial devices was to poll for devices using known usb-to-serial drivers, so in that case, the getPortDescription()
function would append the driver that the device was using to the description string. In 2.11 (and 2.10 and earlier), enumeration is done in a much more uniform and simpler way, so there is no longer any need to poll drivers. As such, that extra piece of the description string was removed. Is this a piece of information that you need?
At the moment, no. I'm actually filtering on FT232R
, not CH34
. I just thought I'd report this bit of 'regression' as someone else might be needing this (which may be future me).
Hi there, I have the same problem (moving from 2.7 to 2.11)
2.7 Output (on Linux), connecting an Arduino Nano compatible board:
getSystemPortName() ---> ttyUSB0
getDescriptivePortName() ---> USB-to-Serial Port (ch341-uart)
getPortDescription() ---> USB-to-Serial Port (ch341-uart)
2.11 Output (on Linux), connecting an Arduino Nano compatible board:
getSystemPortName() ---> ttyUSB0
getDescriptivePortName() ---> USB Serial
getPortDescription() ---> USB Serial
The problem is my software uses the "(ch341-uart)" part to identify the Nano-Compatible board and, without it, i cannot know if the connected board is the expected one (and safely start the firmware upload process...).
I did try to use other methods available (like getManufacturer()) but none of them identify the "CH-341" serial bridge chip.
@hedgecrw is there a way to get for a port the "removed extra piece of the description string" via API ?
Thanks
2.7 test case:
2.11 test case:
2.7 output:
2.11 output:
OS: Linux 64 bits.