System.IO.Ports - custom baud rate 5787 not working

[georgeoprescu]

Platform: RPi v4 Model B (armv71)
dotnet runtime version: 3.1
OS: Dietpi v6.26.3

When using System.IO.Ports.SerialPort class with a baud rate set to 5787 there is no communication with the connected device.
If baud rate is changed to 4800 it works.

If I switch to .net framework on windows, I can connect to the device using either of the bad rates and works just fine.

Physical connection is accomplished in all cases using the same FTDI USB/Serial adapter

Best regards,
George

[danmoseley]

Thanks for the report. Would you like to investigate a little bit?

[georgeoprescu]

Thanks for the report. Would you like to investigate a little bit?

After setting the baud rate to 5787, when calling Open() an ArgumentException with the message: "Value does not fall within the expected range." is thrown.

Thanks,
George

[danmoseley]

I don't know this code at all, but my guess is that we're trying to set that speed, and the OS is rejecting it. Looks like we set it here:

runtime/src/libraries/Native/Unix/System.IO.Ports.Native/pal_termios.c

Lines 364 to 369 in 6072e4d

	#if HAVE_CFSETSPEED
	cfsetspeed(&term, brate);
	#else // on SunOS, set input and output speeds individually
	cfsetispeed(&term, brate);
	cfsetospeed(&term, brate);
	#endif

If you're motivated, the next step is probably to write a small C program that tries to set it explicitly, and see whether it works. If it does not: it's hardware/OS. If it does: it suggests the issue may be in .NET.

BTW, I am not sure whether strace will trace these OS calls. It might be worth a try- you can see exactly what it is doing.

[danmoseley]

Actually I think here

runtime/src/libraries/Native/Unix/System.IO.Ports.Native/pal_termios.c

Lines 513 to 517 in 6072e4d

	#if HAVE_CFSETSPEED
	ret = cfsetspeed(&term, brate);
	#else
	ret = cfsetispeed(&term, brate) & cfsetospeed(&term, brate);
	#endif

and thatt's failing causing us to throw here

runtime/src/libraries/System.IO.Ports/src/System/IO/Ports/SerialStream.Unix.cs

Line 564 in c87e75e

throw new ArgumentException();

[georgeoprescu]

For sure the OS is not a problem.
I use as alternative the SerialPortStream (https://github.com/jcurl/SerialPortStream) and I modified there the libnserial C code in order to support custom baud rates, I rebuild it and it works.
I was hopping that the implementation that comes with netcore 3.x offers a better approach.

I used termios2 struct instead of termios and I ended up with something like:
struct termios2 term;
term.c_cflag &= ~cbaud; //remove current baud rate
term.c_cflag |= BOTHER; //allow custom baud rate
term.c_ispeed = custom_baud_rate; //set the input
term.c_ospeed = custom_baud_rate; //set the output

[danmoseley]

You're saying that cfset*speed does fail, but setting via termios2 does not? I wonder why.

@krwq any thoughts?

[georgeoprescu]

Not exactly, the baud rate is an Enum, that is why it fails to set custom baud rate.
You set an arbitrary baud rate and using termios2 you override that arbitrary baud rate with the custom one

[georgeoprescu]

If it helps, here are some links I used when I had to modify the C libnserial library to support custom baud rate:
https://stackoverflow.com/questions/49025424/uncommon-baud-rate-on-serial-port-linux
https://stackoverflow.com/questions/12646324/how-can-i-set-a-custom-baud-rate-on-linux
https://github.com/jcurl/SerialPortStream/pull/19/files

Thanks,
George

[krwq]

@georgeoprescu do I understand correctly that the OS will correctly transmit at the arbitrary baud rate or will it rather automatically round to a value it supports? Is that support on any Unix or will we have to ship multiple binaries for different flavors?

[KalleOlaviNiemitalo]

Looks like struct termios2 / TCGETS2 / TCSETS2 are not supported on WSL1: microsoft/WSL#2595

[georgeoprescu]

@krwq OS will use the custom baud rate, otherwise the device on the other end would not communicate. As I understood it, and it worked for me, cfsetspeed, cfsetispeed and cfsetospeed tests the baud rate received as parameter against a set on standard baud rates that defined in termios.h (using #define...). From what I learned from others, I used termios2 struct to bypass this check and set the speed to the integer value needed.