You are not logged in.
This problem is bizarre and I'm not sure where to go from here. This is going to take a bit of background to explain.
I'm building a Virtual Pinball Machine. Part of this is the libdof library, the Direct Output Framework library that lets a virtual pinball table control real hardware like solenoids and addressable LEDs. For control of the latter, I'm using a Wemos D1 Mini microcontroller that has an onboard USB to Serial controller chip. libdof talks to that microcontroller via sigrok's popular libserialport package (it actually pulls in its own version of this code but it is the same version as the Arch package). libdof knows what baud rate to talk to the microcontroller with via an XML file that defines the value to use. Yes, this is a USB connection, but given that the micro has a USB->serial chip on it, the baud rate matters.
What I've found is that any values above the standard 460800 rate stopped working sometime around August. Before that I was happily using the default value of 2000000 (2 MBaud). I though I must have screwed up a config file or something, and spent tons of time trying to track down the cause but that wasn't the case. Here is what I know after spending a lot of time researching, instrumenting the test program that comes with libdof, etc.
when the test program that comes with libdof calls libserialport to set a 2000000 baud rate, libserialport reports it was successful. However, this is a false positive. libdof can't talk to the micro and this code reports that the baud rate for that port was not in fact changed but still at the default value of 9600 baud.
stty -F /dev/ttyUSB0If I run the code below before running the test program, everything works. This proves the hardware and cabling is OK, and the port is capable of being set to 2 MBaud. And according to Google Gemini (I know, I know) "When minicom sets a non-standard baud rate like 2,000,000, it likely relies on lower-level, more direct Linux kernel features than the standard termios interface used by libraries like libserialport. This would explain why minicom succeeds where your application fails, even with a "successful" return value from sp_set_baudrate."
stty -F /dev/ttyUSB0 2000000when the test program calls libserialport to set a 460800 baud rate defined in the xml file, libserialport successfully sets the rate according to the stty check in the first bullet. This proves the program is successfully reading from that xml file.
Other users run this software successfully on Mac as well as Linux with the same version of libserialport. I'm following up with them for specific distros and version info
My pacman cache has a glibc-2.40+r16+gaa533d58ff-2-x86_64.pkg.tar.zst, which was in the ballpark of the time this problem showed up. Downgrading to something yet earlier to see if the problem fixes itself carries a decent risk of messing everything up on this, my main box. Don't want to do that.
Minicom can talk to the micro at 2 MB no problem
minicom -b 2000000 -8 -D /dev/ttyUSB0The standard baudrates defined in libserialport all work fine. Anything higher is thought by libserialport to be set but is in fact not. Note that libserialport takes a different path when configuring these non-standard rates
It isn't a permissions issue. I can set the baudrate to the port without sudo and I have a udev rule that sets the device to the uucp group (of which I belong) when I plug it in
[dk@ryzen libdof]$ ls -l /dev/ttyUSB0
crw-rw---- 1 root uucp 188, 0 Sep 11 10:14 /dev/ttyUSB0Once again, this worked a few months ago. Now it doesn't. libserialport hasn't changed in that time. glibc and the kernel have. The hardware is fine. I just can't talk to it at rates above 460800 baud, and the higher rate of 2 MBaud is important. The standard firmware for the micro expects that rate and this thing processes a lot of data in real time. To complicate matters, the sigrok folks (providers of libserialport) are in a rough spot right now. Their server blew apart a while back and all their infrastructure (like their bugzilla) still isn't back. But I don't think this is their issue anyway but something lower down.
What should I try next to get this working again? Something is broken but I don't know what, whether it is specific to Arch, whether it is just because of the newer packages in Arch, etc.
Offline
Have you looked at https://bbs.archlinux.org/viewtopic.php?id=307623?
Offline
Have you looked at https://bbs.archlinux.org/viewtopic.php?id=307623?
No, I didn't see that. Thanks for pointing this out! Definitely looks like the same problem.
Edit: Added my information to that bug: https://sourceware.org/bugzilla/show_bu … =33340#c15
Last edited by DeKay (2025-09-11 21:54:07)
Offline
In the sourceware bug report linked in the previous post, there is a link to a fork of libserialport that works for me. I've asked in https://bbs.archlinux.org/viewtopic.php?id=307623 if Arch should package this version instead of mainline.
Offline