kioto-serial

Crates.iokioto-serial
lib.rskioto-serial
version
sourcesrc
created_at2024-07-08 09:30:22.924337
updated_at2025-01-26 07:27:53.070595
descriptionProvide serial port I/O using tokio.
homepage
repositoryhttps://github.com/strawlab/kioto-serial
max_upload_size
id1295566
Cargo.toml error:TOML parse error at line 18, column 1 | 18 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include`
size0
Andrew Straw (astraw)

documentation

README

Crate kioto-serial

Crates.io Documentation Crate License

Provide serial port I/O using tokio.

Except on Windows (see below), the implementation uses synchronous blocking I/O to the serial port in newly spawned threads (one for reading and a cloned handle for writing) and then wraps these with asynchronous channels.

This crate provides an interface very similar to tokio-serial with a different implementation. Ideally, it can serve as a drop-in replacement. In other words, in Cargo.toml [dependencies] section, you could use

tokio-serial = { package = "kioto-serial", version = "0.1.0" }

and continue with code originally written for tokio-serial.

In Windows, tokio-serial is re-rexported because the approach used here, cloning the serial port handle, simply does not work. Specifically, a blocking read from the port blocks writing. (Potential future investigation: use an async implementation using overlapped I/O based on sources such as serial2 or rust-serial-prototype or implement our own async implementation using overlapped I/O based on sources such as this or this.)

Why write this and not just use tokio-serial?

As noted above, this crate uses spawned threads and blocking serial I/O. Theoretically, this is not optimal because it is an async facade over a fundamentally blocking implementation. So why are we taking this approach?

We were experiencing long latencies from the tokio scheduler when using tokio-serial. Specifically, in a linux program involving simultaneous serial connections to different devices and other tokio tasks such as a webserver and a tokio::time::Interval timer with 1 msec resolution, the ticks from the timer would be very irregular. In the process of debugging, we wrote kioto-serial and found that using it instead of tokio-serial solved this latency issue. Since that point, we have not delved deeper into tokio-serial to attempt to localize the issue. See https://github.com/berkowski/tokio-serial/issues/72.

License

Licensed under either of

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Commit count: 9

cargo fmt