Handling of parity and framing errors in embedded-io / embedded-io-async

[enbyted]

Hello,

The current ErrorKind struct in the -io crates is very high-level. In contrast to embedded-hal-nb it does not expose the typical errors one might encounter (and want to handle) when working with serial ports.

As a concrete example - it is impossible to implement a generic, async or blocking, DMX512 receiver using the current traits - as that requires detecting a break signal. Protocols that make use of 9-bit signalling (often handled using „parity” errors) suffer from the same fate.

Would it be possible to extend the ErrorKind, so that driver implementations (such as embassy-rp) can expose these kinds of errors?

While one could overlook the embedded-io traits, as embedded-hal-nb is the alternative, there is no alternative for the async version.

[carloskiki]

I have the same issue, embedded-hal says one should use embedded-io for Serial/UART, but the ErrorKind type of embedded-io entirely unrelated to serial interfaces, so one ends up always using ErrorKind::Other.