Ubuntu 20.10: hardware_test receive fails

[serialport]

Ubuntu 20.10: hardware_test receive fails

[mlsvrts]

Reproduced this on my system (not including the baudrate failures; those are likely unrelated):

$ lsusb
0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC

$ uname -ar
5.13.0-27-generic #29~20.04.1-Ubuntu

[mlsvrts]

The issue can be trivially fixed by setting the port timeout on my system:

diff --git a/examples/hardware_check.rs b/examples/hardware_check.rs
index 881b680..2107e50 100644
--- a/examples/hardware_check.rs
+++ b/examples/hardware_check.rs
@@ -247,11 +247,13 @@ fn test_single_port(port: &mut dyn serialport::SerialPort, loopback: bool) {
         .expect("Unable to write bytes.");
     println!("success");
 
-    print!("Testing data reception...");
     if loopback {
+        print!("Testing data reception...");
+        port.set_timeout(Duration::from_millis(1000)).ok();
+
         let mut buf = [0u8; 12];
-        if port.read_exact(&mut buf).is_err() {
-            println!("FAILED");
+        if let Err(e) = port.read_exact(&mut buf) {
+            println!("FAILED ({})", e);
         } else {
             assert_eq!(
                 str::from_utf8(&buf).unwrap(),

The default timeout is zero:

serialport-rs/examples/hardware_check.rs

Line 430 in a84a245

port.set_timeout(Duration::from_millis(0)).unwrap();

I'm not sure what the expected behavior of 'read_exact' with a zero-duration timeout is, however.

Edit:

The timeout duration is eventually consumed by either nix::poll::ppoll or nix::poll::poll on posix systems:

serialport-rs/src/posix/poll.rs

Line 32 in a84a245

nix::poll::ppoll(slice::from_mut(&mut fd), Some(timespec), SigSet::empty())

Both of these functions support a format for specifying 'no timeout', however, serialport-rs can't currently express this as its timeout is not optional. I think that supporting Option<Duration> would be a nice feature for serialport-rs, but constitutes a fairly significant change.

For the scope of this issue, adding a non-zero timeout to the example seems reasonable.