Order of plugging in devices can change which device the ttyACM1 link points to, but assuming you run “
ls -l /dev/ttyACM1” and it points at “
bus/usb/001/004”, what do you see from: “
ls -l /dev/bus/usb/001/004” (I’m trying to see what the final node “ls -l” shows).
Regarding ioctls, most hardware on the system is accessed as an ordinary file to read from or write to. Non-standard options (options beyond basic file manipulation) use custom ioctl calls (“I/O control”). These files (e.g., “
ttyACM1”) are actually the result of a driver and any operation on that file is limited to whatever the driver was programmed to handle. Not all serial devices will have the same set of commands available, and so the ioctl will show as an error if either the driver is not loaded, or if the special ioctl operation was not programmed into the driver. Thus this is not necessarily an error unless your end program depends on that ioctl, or if the driver has not loaded. The ioctl failure could just be because your device (when working normally) does not support that feature.
What can you provide in regards to exact information on this device, its name, and any manufacturer links?
Note that the udev rule is just a symbolic link and naming convention (this is a mapping from IDs to names, and has no influence on function). The udev rule created “
/dev/ttyACM1”, and is not created by a driver; this is a pointer to a driver’s resulting file. The actual file “
/dev/bus/usb/001/004” is the result of a driver loading (this is not a symbolic link), and this is what we are interested in. If the driver were incorrect for that hardware, then chances are the driver would have never loaded and there would have been a logged error. We used the udev rule to map a label consistent with an ACM serial UART, but if we were wrong, then we’ve just mislabeled another device and incorrect requests for non-existent functions imply the device will fail. I do think this is the right device though. This is where internet research can help…finding clues as to what the hardware is.
So we have to find out two things: First, is the device at “
/dev/bus/usb/001/004” really an ACM UART? Second, assuming this is the correct device, is the device prepared to function as expected using the software you are using?
The first question can be answered by looking at the manufacturer and device IDs. These come straight from the device, and not the device driver (USB talks to devices, and USB itself is not a device driver to the end device, and so you are guaranteed a reply of IDs will be valid even if our own idea is not valid). Going here, and looking up manufacturer “
0483”, followed by device “
5740”, says this is a serial device (a virtual COM port). We have the correct idea of what the device is, although we do not know if it is really correct to use the ACM driver. I suspect (but cannot guarantee) that ACM is correct because otherwise the driver would have probably failed to load. Ignore the ioctl error, this device may just have a subset of ioctls most UARTs have. Now if we were to find a specific ioctl which the device should have and which is an error, then we would have a true error.
Extending the first question, USB says this is a “ChibiOS/RT Virtual COM Port”. Perhaps that is implemented with an ACM serial UART. Having a company program the device name, and yet be a more or less standard and common actual chip (using a generic driver), is common practice. Still, we do not yet have a guarantee, we only know this is likely correct due to the driver loading. What does a verbose lsusb say? Post the output of:
sudo lsusb -d 0483:5740 -vvv
Note that there is no difference between starting numbering at “ttyACM0” versus “ttyACM1”, but since USB is dynamically hot plug, this means numbering simply needs to be unique to any given device. However, this does make me curious about the laptop this works from. What do you see from this on the working laptop?
egrep -R -l 'ttyACM' /lib/udev/rules.d/* /etc/udev/rules.d/*
I am thinking we could refine the ttyACM udev rule, or perhaps find out if there is a comment in the udev file about what the device really is. Since multiple brands might use the same actual UART, then finding other ways the driver is named could help even if the rule is for some other different brand of hardware. For example, we could put a modified “
60-serial.rules” into “
The second question about whether the device functions as intended might depend on firmware being loaded. Drivers only work if the hardware is what the driver expects, and firmware (for some devices) changes what hardware is present. I do not know what firmware your device needs, if any (I’ve never seen one of these before), but if some sort of user space software is available from STMicroelectronics, then this might include firmware. Should firmware be required, then having drivers present would be necessary, but not sufficient for success. At the very least trying to run this software could produce log info from either the command line or from “dmesg”.
What software do you have to use with this device, and what error or failure do you see from using that software with “
ttyACM1”? Monitor “dmesg --follow” while plugging in the device and then while attempting to use the device.