I was trying to connect with my 3D printer as we already supported that usb-serial chip. As the printer is powered by an Arduino Mega, baud rate defaults to 250000. A rate don’t supported by our Serial terminal app.
Trying to fix this, I see we have a data_rate enum with classic baud rates, and the equivalent constants on termios.h matching enum values, using both a scheme of 1-N values.
So, the easy way would be to just, keep adding constants, but looking at how Linux handles this I see they just have same constants but custom data rates are allowed using a mask constant call BOTHER.
I can mimic this in our termios and device driver , but SerialPort class takes an enum as argument and I feel like forcing an integer into an enum with no defined value may end on issues. Refactoring SerialPort also scares me a bit.
So… how should I proceed? Using just defined constants for data_rates? (any decent list somewhere?). Refactoring SerialPort to allow custom baud values?
There is a partially implemented support for custom baudrates, I tried to copy some code from the BSD, but it’s broken because our size for speed_t is smaller than what they use, and so we can’t fit arbitrary speed values in there.
See https://review.haiku-os.org/c/haiku/+/7068 for details. I think I found a way to make this work there by using the “speed” setting as a divider, instead of a speed. The main difficulty was trying to preserve ABI compatibility with existing apps (otherwise we could change speed_t to a 32 bit type and we could implement the same thing as FreeBSD).
Since I wrote this patch, I had no chance to actually test it and I think the build is broken. If this solution is suitable for what you’re doing, help is welcome finalizing the patch. You should be able to test it with SerialConnect which already allows to set a custom baudrate.
Your patch is almost what I got in mind, but storing baud as a factor of 24Mhz.
However, I’ve checked SerialConnect app and it stores custom baud into an enum member. Yeah, I know enum is just an integer but it feels ugly and I have the impression it may end into some unspecified behaviour. May be it can be avoided with an enum member B_FOO = 0xffffffff so castings are at least inside enum bounds.
Anyway… I have some arduinos to test with. I can give a try to your patch.