Add optional support for embedded-hal traits

[dbrgn]

Implement opt-in support for the embedded-hal serial traits. This allows embedded device drivers to be easily tested on a non-embedded platform like Linux.

This change is useful for using any device driver developed using embedded-hal traits on a regular computer. embedded-hal (often abbreviated e-h) is basically the standard set of APIs for writing generic drivers with Rust (HAL / Hardware Abstraction Layer).

For example, here are the traits for a serial device: https://docs.rs/embedded-hal/0.2.5/embedded_hal/serial/index.html If I write a device driver for a device that communicates over serial, then I can use that driver with any microcontroller hardware support crate that implements these traits. For desktop computers with a full operating system, serialport-rs can play that part and translate generic "write to serial" and "read from serial" calls to the actual calls that the operating system supports.

Note: Marking as draft until embedded-hal 1.0 is released. I plan to regularly update the branch to keep up with upstream developments. Once the stable version is out, we could squash the commits.

[dbrgn]

(Also, thanks a lot for forking and maintaining! This PR is based on my MR here: https://gitlab.com/susurrus/serialport-rs/-/merge_requests/76)

[sirhcel]

Thank you for this PR! I would really like to see it merged. As embedded-hal 1.0 is in the making for quite a while and I've got the feeling that it still will be: What about supporting both, the 0.2 and the latest alpha of 1.0? This will allow using the stable embedded-hal traits by now and allows playing with the upcoming ones.

I've made a proposal for that in my my branch e-h-coexistence.

I would also love to have an example and test for demonstrating the use of embedded-hal serial traits.

Do you know of a driver using them as a showcase for an example? Otherwise something like the string reversing from the Discovery book will do (though it looks to me that it could use a little spring cleaning for sparing out the nasty hardware details and actually using the read and write traits).

For testing the trait impls, a simple loopback test could do the job. May be we could piggypack on examples/hardware_check.rs.

[dbrgn]

What about supporting both, the 0.2 and the latest alpha of 1.0? This will allow using the stable embedded-hal traits by now and allows playing with the upcoming ones.

Would definitely be doable, although the actively developed projects often moved to the alphas to keep up with the changes...

I would also love to have an example and test for demonstrating the use of embedded-hal serial traits.

Do you know of a driver using them as a showcase for an example?

I work on https://github.com/dbrgn/espresso, here's the Linux-serialport example: https://github.com/dbrgn/espresso/blob/main/examples/linux.rs The driver accepts a serial port implementing the serial trait from embedded_hal, and because the serialport-rs branch/fork implements that, I can just pass it in.

[dbrgn]

Updated to alpha 9.

The non-blocking embedded-hal traits have now been split off into the embedded_hal_nb crate. I tried to implement both blocking and nonblocking traits, but hit a small issue. Before this will be merged, there should either be two separate trait implementations, or the dependency on embedded_hal should be removed in favor of embedded_hal_nb.

Edit: I pushed support for both blocking and non-blocking trait support.

[akauppi]

https://blog.rust-embedded.org/embedded-hal-v1/

I will have a need for this, in.. May.