Async version with Tokio/smol

[gabrik]

Hi,

First of all, thank you for this very useful crate, I was wondering if there is any plan to have asynchronous features for it.

If not do you have any suggestions on how that can be contributed?

[de-vri-es]

Hey!

We'll need a cross-platform asynchronous interface to serial ports. I vaguely remember that there were some issues with asynchronous serial ports that prevented me from attempting it.

However, I would be glad to see information or PRs to show that it is feasible :)

As a workaround, I'm running a separate thread (could use tokio::spawn_blocking() or just std::thread::spawn()) that controls the motors. I use a mpsc channel to send commands to the motor control thread. Each command includes a oneshot channel to get the result of the operation back to the caller (tokio already provides both channel types).

[gabrik]

Thanks for the fast response!
I think that tokio-serial or/and mio-serial provide cross-platform support for serial ports, at least I used both here: https://github.com/gabrik/hls_lfcd_lds_rs and I had no issues on Linux or macOS, not yet tested on Windows.

I may try to craft a PR, my guess is that the main changes are going to be in bus.rs and in almost every file in instructions folder, is this a correct assumption?

[de-vri-es]

As it stands, yeah. It's a bit of a shame to duplicate all of the instructions for sync/async, but they do have to read the response message(s), so I don't see how we could avoid the duplication easily.

Note that mio-serial and tokio-serial do suffer from the same strange API choices that eventually led me to write serial2 (different structs on different platforms, and everything through a Box<dyn SerialPort>). I may make a tokio-serial2 at some point. But for now, tokio-serial will do just fine. I can swap it for a new serial port crate later with a major version bump.

[gabrik]

Hi, you can find a PR here: #2 please feel free to comment and give feedbacks