Can't seem to be able to read data on Windows about serialport-rs HOT 15 OPEN

I just opened a PR with a possible fix to the problem. If you could check it out and test if this fixes your problems, it would be much appreciated.

Tested and worked for use with RPI Pico

from serialport-rs.

I'm also experiencing this issue, also with a USB CDC-ACM device

from serialport-rs.

Is there a solution to this problem now?

from serialport-rs.

@vladimire-chen Do you see the same behavior if you use PR #55?

from serialport-rs.

let mut data_buf = vec![0;1024]; 
while port.bytes_to_read().unwrap() < 1024{
    thread::sleep(Duration::from_millis(1));
}
println!("{}", port.bytes_to_read().unwrap());

port.read(&mut data_buf[..]).unwrap();

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Custom { kind: TimedOut, error: "Operation timed out" }', src\lib\serial.rs:64:42
stack backtrace:

@mlsvrts I explicitly waited until the number of bytes reached my requirement before performing the read operation, but it still times out, which makes me wonder

from serialport-rs.

@mlsvrts I am also seeing this issue with the above code, including with #55, in addition to some code I tried with a minimum test of windows-sys (as opposed to winapi). I can open the COM port, and I see that the program is actually holding the port (other programs can't access the port while the program is running), but I only receive timeouts when doing read operations.

Programs such as putty and Tera Term work as I'd expect. Also using packages like serialport for NodeJS work too.

from serialport-rs.

Currently experiencing this issue when trying to read data from RPI Pico through serial. Always reports 0 bytes to read, but serial output can be read from other serial monitoring tools.

fn main() {
    let mut port = serialport::new("COM7", 115200)
        .timeout(std::time::Duration::from_millis(1000))
        .parity(serialport::Parity::None)
        .stop_bits(serialport::StopBits::One)
        .flow_control(serialport::FlowControl::None)
        .data_bits(serialport::DataBits::Eight)
        .open()
        .unwrap();

    loop {


        let buffer_bytes = port.bytes_to_read().unwrap();

        println!("{:?}", buffer_bytes);

        // Read data from the serial port
        let mut buffer: Vec<u8> = vec![0; 100];
        let bytes_read = port.read(buffer.as_mut_slice()).unwrap();
        let message = String::from_utf8_lossy(&buffer[..bytes_read]);
        println!("Received: {}", message);
    }
}

from serialport-rs.

I just opened a PR with a possible fix to the problem. If you could check it out and test if this fixes your problems, it would be much appreciated.

from serialport-rs.

Continuing here the discussion opened on PR #94 (see my comment here), since it seems a more appropriate place. A colleague used the same USB device on the same port, with the .net SerialPort API and with the code I wrote using this crate. The settings are exactly the same, but the behaviour is different. I'm looking at the source code of the .NET framework here to see if there is any difference in the implementation, but I'm not sure exactly where to look at. In the mean time, if anyone has any suggestions I'd be happy to test the fixes and open a pull request.

from serialport-rs.

Continuing here the discussion opened on PR #94 (see my comment here), since it seems a more appropriate place. A colleague used the same USB device on the same port, with the .net SerialPort API and with the code I wrote using this crate. The settings are exactly the same, but the behaviour is different. I'm looking at the source code of the .NET framework here to see if there is any difference in the implementation, but I'm not sure exactly where to look at. In the mean time, if anyone has any suggestions I'd be happy to test the fixes and open a pull request.

You should check if/how .NET is setting windows COMTIMEOUTS; my guess this is the root of your issue.

It's also my understanding that .NET can/will set DTR differently from this library. The simplest thing to do is measure and compare the state of the various flow-control serial pins to determine if this is your issue -- I have seen some USB CDC serial implementations that have 'wait for DTR' or other such flow control.

USB CDC host-side can signal both DTR and RTS to the device driver.

Edit:

You can also try mode COMX /STATUS for checking the sideband signal states from a command prompt.

from serialport-rs.

A little update:
I couldn't find any fundamental difference between the .NET library and this crate. However, on another Windows machine, the software works with most devices. Just a couple of them don't work.
The firmware guy also specified that our serial ports are virtual, so the flow control should be managed by the USB protocol, however he's not sure.

The simplest thing to do is measure and compare the state of the various flow-control serial pins to determine if this is your issue

About this, I have no idea how to do it.

Also, if I don't set a timeout, the call hangs indefinitely.

What's weird about all this is that it works for most devices on most machines, but I can't figure out what's the root cause of the issue for those combinations of USB devices and Windows machines where it doesn't.

from serialport-rs.

I checked on two Windows machines (Windows 10 and 11), using three different devices each: an Arduino Leonardo (USB controller integrated into ATmega32u4), an Arduino Nano (legit FTDI chip), and an RP2040 (Raspberry Pi Pico, also with CDC). All six configurations fail. Both with my code that runs this crate, as well as another person's code (Youtube Tutorial, cloned their GH repo and ran it), who also uses this crate. Is there anything I can do, like tell cargo to use the PR #94 rather than the latest?

from serialport-rs.

Another voice here. Interfacing with a commercial instrument using I think a FTDI chipset. I can read the first time I run the program after plugging in the device, but not subsequent times (I get the timeout). I tried PR#94 build (for anyone else looking you can use serialport = { git = "https://github.com/serialport/serialport-rs", rev = "310ab9c64b7bbeaea52255a7a4059f2d798c8214" } in your cargo.toml) and it didn't fix the issue for me.

Turns out you can restore your serial port access for one call per program with a workaround. I've worked around it using the 4.2.2 release with a python script that opens and releases the serial port before the rust program runs.

import serial

with serial.Serial("COM4", 1200, timeout=2) as ser:
    _val = ser.readline()

Then I just run python scripts\reset_serial.py && cargo run to do my debugging. Not great by a long shot but it works.

from serialport-rs.

Further investigation reveals this workaround doesn't always work. Seems to work if your rust program runs quick enough (before there's any more data in the serial buffer). Yes, seriously. If your program takes longer to build then it just hangs. I've moved to calling the python script in a process window inside rust just before I make my read calls and that seems to work more reliably.

from serialport-rs.

We need an option to toggle on DTR (Data Terminal Ready). I tested in C# and that was the only way I could get responses from the device I was trying talking to. By default it is off in the standard dotnet serial library.

EDIT: Going to try this:

    pub fn open_via_port(&mut self, port: &str) -> Result<()> {
        let port_settings = serialport::new(port, 115_200)
            .data_bits(serialport::DataBits::Eight)
            .flow_control(serialport::FlowControl::None)
            .parity(serialport::Parity::None)
            .stop_bits(serialport::StopBits::One)
            .timeout(Duration::from_secs(5));

        let mut port = port_settings.open().map_err(|e| {
            let err_msg = format!("Failed to open serial port: {} ({:?})", &port, e);
            error!("{}", err_msg);
            anyhow!(err_msg)
        })?;

        port.write_data_terminal_ready(true)?;

        self.port = Some(port);

        Ok(())
    }

EDIT: This worked for me

from serialport-rs.