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.
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.