Linux, udev and USB Serial ports
frank freedman
Posts: 1,983
I miss having real serial ports on systems. A port was a port was a port and where they were supposed to be, they were. None of this plug in and maybe it is at the same place it was last time. My preference is to use the prop programing link for just that and a separate terminal for putty to watch things or as an output for whatever I am expecting. But if something is plugged in before or after the other thing, the ports may be wrong, i.e. ttyUSB0 has become ttyUSB1. Now putty is confused and BST will not identify much less load the board in use.
Enter udev. After a couple days of experimenting, I have finally gotten the hang of using udev. Though on a 1 1 2 level rather than a 2 2 4 level. So far, I can write rules so that the prop plug, C3, and a prop project board are all recognized individually and their own /dev/whatIcallit symlink can be created. I have taken to using the plug serial number since the device and mfr id's may be the same leading to the which plugs in first issue above. I did find that FTDI has a method, FT_PROG to change the serial number among other tings; it seems to be windows only at this point. And for now it works on the serial numbers udev recognizes.
When time permits, a bit of additional scripting can report back what I have plugged in and maybe later enable adding an additional device when something new gets into the mix without having to go into rules each time. So, for now the rule creates a symlink to the ttyUSBx created when it was plugged in. Doesn't seem to matter as long as I reference the symlink. If anyone does it differently/easier, it would be interesting to see. Yes, rules are case sensitive, went round and round a while because serial is not the same as Serial (originally lazy edited idSerial leaving Serial...Dohhhhh)
from /etc/udev/rules.d/99-USB-Serial.rules # is comment
#
SUBSYSTEM=="tty", ATTRS{serial}=="A7PPLRPG", SYMLINK+="PropPlug"
SUBSYSTEM=="tty", ATTRS{serial}=="A8PropC3", SYMLINK+="PropC3"
SUBSYSTEM=="tty", ATTRS{serial}=="FTWV54DJ", SYMLINK+="PropPrj1"
model line. serial above was used because idVendor and idProduct is same on 2 of the three
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A86aC72d", SYMLINK+="MyThing"
minor point, putty will work with the symlink, but I need to run ll -l to see the link that BST will be able to use so for the PropC3, it will need ttyUSB2 (this time)
$ll -l
lrwxrwxrwx 1 root root 7 Sep 8 22:25 PropC3 -> ttyUSB2
lrwxrwxrwx 1 root root 7 Sep 7 22:47 PropPlug -> ttyUSB1
lrwxrwxrwx 1 root root 7 Sep 8 22:25 PropPrj1 -> ttyUSB0
@"Moderator Monkey" Any idea why the line I called model line formatting looks like screaming? Thx
Comments
The CP210x tool should not be missing here.
—▷ https://github.com/DiUS/cp210x-cfg
And I haven't found a way to "individualise" the CH340 USB serials yet and therefore avoid them like a pest.
In the early 2000's an engineer complained that USB added extra stuff that wasn't needed to a device so he only used Serial.
At the time I thought that USB was great because the computer would know exactly what was plugged into it.
He was exactly right!
Serial is so simple.
With a classic serial I have to keep in mind what I plugged in where because the other end does not identify itself and having more than 4 serial interfaces started to get really expensive and sometimes even driver hell because of non-standard chips in these expensive as hell cards. That only did fit for stuff you connected once and then stayed connected like mouse, modem, plotter, printer, ... if you could live with low speeds.
With USB and not having such UDEV tricks it is even a bit worse. Stuff you plugged in over a longer period may show up in different order after a reboot. Additionally the USB sockets are so badly designed, that its designer should even get sued!
Adding these self defined links to the interfaces makes one USB problem bearable where UDEV exists.
Neither old serial, nor $SOMETHING over USB-serial is/was heaven.
On Mac and Linux, and presumably the BSDs too, there is /dev/serial/by-id/*. eg:
They'll be Udev entries I guess. The whole branch from /dev/serial is virtual and vanishes when no USB comport devices are present.
USB was designed by a committee so everyone got a bit of what they wanted, but IMHO nothing was tied together properly. On top of this, there is so much overhead and complexities even MS took years to get something working reasonably well.
OTH Serial was so simple - just needed an identifier command.
Yes, serial was sooo simple.
Four different Plugs, Gender Changer, Nullmodems, incompatible Baudrates, incompatible Voltages, DCE vs DTE.
Na, simple is not the right word,
Mike
All those were a non-issue Mike. They were all easy to diagnose and action a remedy. Just needed some desire to understand it.
Binaries/drivers/OS misbehaving can't be fixed by some soldering. Maybe if everything was free source level code from the outset USB might have been sorted out earlier. We were dependant on decades of gradual improvements to get any reliability of the software for USB.
No kidding. One of my clients is in a sticky situation: they cannot get the source code for their product because the programmer that wrote it never provided copies to them, and won't now because the previous owner owes him money. This software connects to an XBee to talk to laser tag weapons in the field. I thought I'd use WireShark to look a the traffic and pull the packets out. What a nightmare given all the stuff going on with the upstream (of the USB chips) side of things.
I ended up putting on my hacker hat and connecting an XBee/USB adapter to the software. That adapter breaks out the TTL level serial lines so I added a header and brought the XBee DO and DI signals (3.3v TTL) to a P2 for display. It works great; I only see the packets in and out of the XBee, and I mark them with timestamps so I can see typical response times.. I've got another week of documenting messages, but after that we are free and clear. We've already started on a new product to replace the old. And yes, source code will always be maintained inside.
The “REAL” serial was simple, defined, and easily understood. Both async and sync.
BUT the micros of the late 70’s and early 80’s stuffed it !!! This includes Apple who used DB25F instead of DB25M for DTE, followed by IBM who correctly used DB25M for serial DTE and then stuffed it by using DB25F for parallel to drive centronic printers etc !!!
On a DTE DB25M TXD (out) was pin 2, RXD (in) on pin3. A crossover was 2-3, 3-2, 7-7, 4+5-8 (and same on the other end), 6-20, 20-6. Clocks (for sync) were TXC on 15, RXC on 17 (both inputs), and if external clocks were supplied were on pin 24. Forget where RI was 21 or 22 ? Cut my teeth on this 50 years ago so hope my pin recollection is correct.
I designed and built Sync ASCII to EBCDIC converters for connecting various minis and mainframes together for data exchange - customers were ICL, IBM, DEC, Wang, Singer.
Ultimately built a board for Apple //e and Apple /// to connect to minis and mainframes for 2780 batch file transfer and 3270 bisync to emulate 3270 terminal on 3274. We sold this to Apple USA in 1983-4 and produced them for Apple. Unfortunately the Apple //gs design was terminated and not many were sold (~2000 IIRC). Years later the //gs design was completed but it was too late. This was how Luke, Chris and I started NetComm - in my garage - actually I partitioned the back of the garage into an office - the air conditioned garage housed my Singer/ICL mini - yes they were the size of a garage (really)
Somewhat off-topic - Today I, again, looked up "how does G-Sync work?" and "how does FreeSync work?" and "how does Adaptive Sync work?" ... and found other people asking the same question ... but not once did I find even an attempt at an actual answer. In every case the only answers, if any, were what it does rather than how it's done.
I say somewhat because the details of how something works is what fascinates me. I learnt all about UARTs because of this fascination. So they were never any trouble to me.
Actual answer to that question: It basically just allows the computer to extend the VSYNC period of the video signal until the next frame is rendered. I think it's literally just that (plus signalling to the monitor that adaptive sync is used).
I use CH340G based interfaces with track mods to give proper 3v3 serial, they work perfectly to 2 Mbps
I'm running Devuan and have no problems with udev, always come up /dev/ttyUSB0
Debian or Devuan running on ARM64, no problems
OpenBSD always comes up /dev/cuaU0
they're cheap and just work.
Yeah, I've come to the same conclusion. I found a hint in some Linux kernel code, and put two and two together from there. Especially when I discovered Display Port uses a locked data rate. That forces a wide ranging blanking interval.
The search was to see if I could find anything definitive. The point is this is becoming all too common a problem where the Web is being filled with marketing talk and seems to be losing the knowledgeable tech talk.
Also, G-Sync is supposedly a little different. I was curious to see how that worked too.
I DID NOT CLAIM THE OPPOSITE!
But plug in multiple CH340ers and compare their USB information. Do you still know which one is which papoy by looking at that or the device names?
FTDI-FT232* and CP210* have either different random serial numbers when you get them (FTDI) or all the same value in there (CP210*) but this info is changeable for both of them. That way UDEV and similar services on other OSes can add links like "My1stPropellerBoard" or "ESP32-007" to them.
And I sometimes have a lot USB papoys plugged in, so I really benefit from avoiding CH340ers.
WCH says this on their website
CH340C/N/K/E and CH340B have built-in clock without external crystal oscillator. CH340B also has built-in EEPROM for serial number configuration.
CH343P has a built-in EEPROM, which can configure parameters such as chip VID, PID, maximum current value, manufacturer and product information strings.
The chip has a built-in Unique ID (USB Serial Number).
So I think some versions of CH340 / CH343 can support info changes.
Then those with (EE)PROM will have a chance to stay here, if I additionally can find the tool to change the IDs as open source.
So far I only have seen CH340ers without this feature in e.g. far east Arduino- and ESP-boards.
I will let you know when I get around to building some up.
I have pcbs and chips for CH340 N, C, G, T. C & N don't require external xtals.
Yes, I think it is only the CH340B that has EEPROM, and the CH343P is quite a new part.
The Data sheet mentions :
Through the configuration software CH34xSerCfg.exe provided by the chip manufacturer, you can flexibly configure the chip’s manufacturer identification code VID, product identification code PID,
Parameters such as maximum current value, BCD version number, manufacturer information and product information string descriptor.
but I cannot find that CH34xSerCfg.exe ?
lcsc shows CH340B in stock, but at higher prices than CH340C - it seems the CH340B is largely pin compatible with CH340C ?
lcsc have order code for the faster CH343P (QFN16) but none in stock yet.
CH340 B, C & G are 16-pin pin compatible excepting pins 7 & 8 which are XI & XO on the G, and RST & nc on B and nc & OUT on C.
Seem to recall the CH343P has some reason why it wasn't a goer for me.
Just soldered one each of my CH304N and CH340C boards. Windows doesn't recognise them. Going to try Linux before I try and locate windoze drivers.
Update:
Both work under Linux
BUT...
Vendor 1a86
Prod 7523
bcdDev 2.64 for CH340C and 2.34 for CH340N
Mfr=0
Prod=2
S/N=0 <---
Driver CH341
But on the original topic, if you have multiple devices plugged in, which one is which? As one poster noted his always come up as ttyUSB0, of course in Linux, the first one it sees will be ttyUSB0. Then each one following will be xxx1, xxx2, etc. Still with no real way to see which is which for sure (well there is, but it's not very friendly). By using unique device characteristics, you can have UDEV assign a "name" to the device and then use that name when possible for your devices. In the case of USB serial plugs, the way I did it results in the "name" being linked to a ttyUSBxx device. You don't really have to care which was assigned to which ttyUSBxx if you use the "name". You could refer to the port either way, and in fact if you use BST, you will have to use ls -l /dev to see which link is tied to which ttyUSBxx as it does not seem to recognize or allow anything other than ttyUSBxx (or comx) for the serial channel to find/program a prop with (or so it seemed when I tried it out; could be wrong so I'll revisit BST again).
Another alternative is the method Digilent uses. The Discovery2 initially starts as a USB, but when its driver runs, the ttyUSBxx it grabbed is dumped and its own connection method takes over. the ttyUSBxx it used is available for other use.
I have more hacking on this to do. So far, the link works, a script can be started when udev sees the device changes, but now working on a script that will pop up showing the links rather than have a user have to do the ls each time is next. Currently only have FTDI so with the FT_Prog they can all have a unique serial number. As long as there is something unique to each device that can differentiate, using udev to create the links will work. Also a script to add the name and serial number to the udev rules file will be nice to use.
by-id is specific to the adaptor, doesn't have any random or numerical assignment at connect time that I know of - https://forums.parallax.com/discussion/comment/1528438/#Comment_1528438
have you got a 3v3 supply on that board to pins V3 and VCC ?
my board had a 5k res in series with tx when running 5V into a 3v3 board,
dirty fix but stops the smoke being released.
On the CH340C I have a resistive divider on the TXD output. I used a 1K5 series followed by 3K to Gnd so this splits 5V to 2/3 = 3V3 so ideal. DTR is direct out as it goes via a cap anyway. Fits nicely on my RetroBlade2 P2 board.
On the CH340N I used a 3V3 regulator.
I have built one of each and they work but not tried on P1 or P2 boards, nor tested max speed yet.