开云体育

Hi Lonney.

Yes, those links work too, but the problem is, not that one or other style of link works or not, is that the default links/symlinks created by the OS, can change whenever it is kicked into re-enumerating USB devices at Boot, or restart time, or whenever the USB subsystem changes, as devices are added or removed.

That is in effect what happens when RF gets into a USB lead and messes with things...? They often get assigned in a different order than they did the first time!?? So, even the serial/by-id values can change, and ruin your day.

It causes real chaos, in cases (such as here) where I have multiple serial devices (not just radio's, but a GPSDO and other USB/Serial connected devices in the shack.? (As well as two or three USB audio devices!)

If you just have one such USB serial device, and one only external sound I/O, you likely will never experience the chaos that can happen.


Using udev rules, based on some unique feature of a device (typically a serial number, if that exists, or some other unique info, take care, the VID/PID values are generally not unique) NOT based on what the OS did, will always work the same each and every time.

Consider the not uncommon event of RF in the shack, that can cause a USB device to "drop out", the OS then "forgets" it, but when the RF has gone, the device "re appears" and everything is re-enumerated.?? THAT is when the mayhem can happen, not just with Linux, but Windows and other OS's that support USB devices in the same way, as is the standard way these days..

Using:-
udevadm info -a -n /dev/ttyUSBn

(where n is 0, 1, 2 etc) does list a lot of good info, but in the case of my two main PC's (the currently sick HP and this Dell) that internally have at least two "layers" of dynamic hardware such as PCI and USB subsystems, each boot usually results in a different I/O "path" to an externally connected device, even if is physically connected to the same physical USB "port".

The Dell XPS laptop I'm using at the moment, has two internal PCI bus's, each of them has a collection of internal USB Hub's, that as well as supporting the external devices, also support the keyboad, mouse pad, internal sound system, some aspects of the video system (default LCD screen, and an external HDMI device if connected (and that too it seems can "carry" USB traffic between PC and "Monitor") as well a several other internal sensor type devices, battery state monitoring and temperature sensors etc.

Quite how exactly the combination of it's BIOS, UEFI and OS manage to bring all that up into a usable and generally stable system is quite amazing!

"Udev rules" when configured well, work reliably and consistently in every case, but ONLY where there is something unique about any particular "device" that is not assigned dynamically on a cold or warm start...

The obvious value to look at would be the "serial number", as that ideally (I know...)? "Could" be unique amongst a particular class of devices at least.? But the device makers are somewhat lax in that respect.? It seems Icom, and possibly other Ham rig makers may do the right thing, as does FTDI, but 99.999% of the low cost genuine (as well as the fake/counterfeit) devices do not.

Some, have the ability to use custom information held in an external ROM of some sort, using a microwire bus to communicate with it.? If present, the custom information in it will be provided to the OS when enumerated, instead of the hard coded info in the peripheral chip itself.

See the CM108 sound codec data sheet for example...


Scroll down to the "Reference Application Schematic"? (Page 27 of 28 in the file.)
U3 a 93C46 is a small EEPROM for such needs, connected to pins 2, 3, 4 and 5.

(Page 14 has the format of the needed data for that external EEPROM too.)

Therefore, it could be possible (eyesight and tooling permitting) to retrofit such an EEPROM "dead bug" on top of the codec chip perhaps.

(There is ISTR one Ham USB Audio interface device, that has lands for such a chip provided on the underside of the board, but I forget which one.)? Of course, you first need to program the EEPROM with the correct data in the correct format.

The combination of a "Genuine" FTDI USB serial bridge device (that already has a unique on the planet serial number) and with a CM108 + (programmed) EEPROM would with an example udev rule, solve the issue once and for all, perhaps.

But why would mass market developers do that, Ham Radio is a tiny & trivial marked compared to the general throw-away gadget market these days.

You pay your money, and take your choice.

73.

Dave G0WBX
(Who's eyesight is not good enough for such electronic microsurgery these days, even if I had the tooling to hand!)

-- 
Created on and sent from a Unix like PC running and using open source software: