Some fixes I had to do to make serialport-rs work on MacOS

[berkus]

Here's the diff.

I'm not sending this as a PR because it's not a PR-quality code and just a quick patch of things that didn't work, like #22 and disabling IOSSIOSPEED that does not work on MacOS.

Maybe it helps you get some ideas for fixing it properly.

[jesjos]

I had a project that failed to behave correctly (reading garbled bytes from a serial device) on macOS. I tried the patched code by @berkus and everything worked just fine.

[sirhcel]

Thank you very much for this issue report! I had a first look at this issue by

• Receiving some data on macOS with receive_data sent from Minicom on Linux
• Sending some data from macOS with transmit to Minicom on Linux

The first did not show any received data at all. The data sent from macOS to Linux showed up in Minicom without any issues. This is not the behavior I would have expected here.

But I did not receive any garbled data. @berkus and @jesjos could you give please some details on the scenario you are experiencing the problems with? Like communication settings, transmission directions, ...

[jesjos]

Thank you for your quick reply, @sirhcel !

I'm sorry I didn't provide a full bug report.

My setup is this:

• Communicating with a serial device that uses a fixed baud rate of 115200
• I set baudrate as expected using the serialport-rs
• I read two bytes, I expect them to be little-endian 9
• Instead, I get something like 0x9c

I can actually get the vanilla serialport code working if I use some other serial reading implementation to set the baud rate first. So in my case, I use a java library to read the correct two bytes, then I run my rust code and it works fine. But after restarting my rust code it goes back to the wrong baud rate. I suspect something is fishy with how the library sets baud rates, but my skills aren't enough to figure out exactly what.

I'm running macOS Monterey 12.6 on an Intel mac.

[DanielJoyce]

I looked into this long ago and there is another ticket open that says baud rate is ignored.

I remember looking at the code and seeing some of the settings specified in the constructor not making it into the lower level serial settings.

[sirhcel]

Thank you very much for your feedback! The last days before Christmas are quite busy and I will look into this afterwards. It looks like there is a need for some testing as well.

[berkus]

@sirhcel thanks for looking into it!

[Ali-Amir]

I'm experiencing similar issues as #22 (ENOTTY when opening a socat/TTYPort::pair port on MacOS). Is there anything we could do to help with getting a fix? Please, never mind. With the latest version 4.2.1 and using baud rate 0 works when connecting to a virtual TTY port.

[jamesmunns]

Just noting that this issue still exists with M2 macs. I was previously using serialport 4.2.1, and switching to @berkus's branch made things work.

This was pretty reproducible, and I can debug things if necessary. @jessebraham is there anything I can do to get this to a mergeable state?

This was with 115200 8N1 serial, using a Sipeed RV-debugger-plus.

[StonyBoy]

I have not yet tried the patch supplied in this issue, but I can confirm that the problem is also seen om intel based Macs (garbled characters or none at all).
For now I have just fixed my MacOS dependency to v3.3.0 as this works perfectly on my setup.

[astraw]

@StonyBoy this sounds like it might be the issue @KaSroka reported at #133 (comment).

With which version of serialport-rs are you experiencing the problem and can you please provide steps to reproduce it?

[StonyBoy]

Hi @astraw:

I was also using v4.3.0 initially and I also used the suggestion to set the baud rate explicitely as mentioned by @KaSroka, but that did not change the behaviour for me.

I am using serialport-rs in a unpublished serial client/server program that I am currently working on, but i am mainly just opening the port (connection to a Beaglebone Black over USB/UART) like this:

fn do_open(opts: &CmdLineConfig) -> Result<Box<dyn SerialPort>, serialport::Error> {
    serialport::new(opts.device.to_str().unwrap(), opts.baudrate).timeout(Duration::from_millis(100)).open()
}

and then looping in a receiver thread passing the received bytes to the other parts of the program:

            let mut serial_buf = vec![0; 32];
            match rxport.read(serial_buf.as_mut_slice()) {
                Ok(cnt) => {
                    info!("Received: {cnt}");

The baud rate used on the BBB is 115200 and N81...

BTW: That works fine in v4.3.0 when running on Linux.