Re: Configuration of the RGA200 communication baud rate

[Charter via Tech-talk <tech-talk at aps.anl.gov>]

I remember that there use to be a method to modify the set of possible baud rates to include 28.8 at the expense of others.

Searching with “linux serial all possible baud rates” gives

Non-Standard & Higher Rates

For rates beyond the basic set, especially for modern devices or specific protocols (like DMX512 at 250k), use:

• setserial: Use setserial /dev/ttyS0 baud_base 3000000(example base clock) and setserial /dev/ttyS0 divisor <N> to calculate precise rates like 250000.
• termios2: Use ioctl(fd, TCGETS2, &tio) and ioctl(fd, TCSETS2, &tio) with BOTHER and c_cflag |= BOTHER for custom speeds. 

How to Check/Set Rates

• stty -F /dev/ttyUSB0 9600: Sets baud rate for USB-to-serial adapters.
• stty -a: Lists current settings, including baud rate.
• setserial -a /dev/ttyS0: Shows port info and available base/divisor settings for hardware-level configuration. 

Key Limitation

The actual range depends on the serial hardware (UART) and its clock, which Linux exposes through drivers, allowing for rates like 1M, 2M, 3M, 4M, etc., though accuracy varies. 

John

On Jan 13, 2026, at 3:52 PM, Eric Norum via Tech-talk <tech-talk at aps.anl.gov> wrote:

I'm inclined to agree.  Adding a bunch of kernel/platform-specific ifdef’s to drvAsynSerialPort.c isn’t very appealing.

My first thought at a workaround was to suggest invoking an iocsh ’system’  command to run a python program to set the line rate after all calls to asynSetOption.

This *might* work as long as read timeouts never change — changing a read timeout results in a call to tcsetattr() which would overwrite the speed set by the python program.  Pretty fragile, though.

Or perhaps there’s a way to enable 28.8kbaud in the kernel and thus in termios.h?  The ASYN driver will allow this speed if it’s present in termios.h.

On Jan 13, 2026, at 12:09 PM, J. Lewis Muir <jlmuir at imca-cat.org> wrote:

On 01/13, Érico Nogueira Rolim via Tech-talk wrote:

Just something to note if anyone wishes to use that post as reference (and the recent glibc support isn't enough). It mentions an issue with including kernel headers:

I ran into some #include hell with asm/termios.h, especially if I already had the normal termios.h included elsewhere, so you might have to copy relevant struct definitions into your own code if you can’t get it to work (I know, nasty!). The other thing to keep in mind is that the definition of NCCS might be different between your libc and kernel, so you need to make sure you’re using the kernel’s definition of NCCS. I believe asm/termbits.h has the correct NCCS and structures defined.

The kernel docs explicitly recommend copying struct definitions into userspace code that uses syscalls/ioctls directly. That way you can be sure of what version is in use, and you can name structs appropriately in order to avoid any conflicts. This can get messy if the kernel definitions vary by architecture, and then violating that recommendation becomes more reasonable, so I hope that's not the case.

?? Sounds like a terrible idea to me.  If kernel-related structs are
needed from userspace, the OS should provide appropriate header files
defining those that are either shared by userspace and kernelspace thus
ensuring that they're consistent, or, if separate sets for userspace and
kernelspace, are at least guaranteed to be consistent with each other.

Lewis

— 

Eric Norum

eric at norum.ca