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.

[guillaume-michel]

same here!
This is very frustrating!
We might end up implementing our own traits and wrap uart implementation to satisfy the traits. All that, just to get accurate error messages.

[jannic]

This indeed looks like a disadvantage of handling serial ports like generic data streams and modeling them after std::io types. Note that serial ports on linux seem to have a similar issue, https://stackoverflow.com/questions/41595882/detect-serial-break-linux. The serialport crate doesn't handle this either: serialport/serialport-rs#31.

I feel like it's more likely that embedded developers run into this issue than software developers on general purpose operating systems, so it would be nice if we could find a solution.

Technically, it would be possible to add a new variants to ErrorKind, without adding a breaking change because ErrorKind is non_exhaustive. However you wouldn't be able to rely on actually getting that error: Older drivers will still return Other.

[jannic]

We talked about this ticket in today's wg meeting.

The conclusion of the discussion was:

• Support for break handling sounds very reasonable
  • Likely not as a separate ErrorKind, because these kind of errors would be very UART specific and won't make sense on eg. TCP connections.
  • Instead, we could define a new trait BreakError { fn is_break(&self) -> bool; }, and UART drivers could implement that trait for their specific error types in addition to embedded_io::Error. That way, it only UARTs implementing that trait could be passed to a DMX512 driver.
• We were less sure about parity/framing errors. Are there real-world use cases?
  • Using it for 9-bit signaling doesn't sound very convincing (a separate trait for 9-bit capable UARTs, that could be implemented either natively or via some parity based hack, would be better.)

However, only a few people were present, so there may be other ideas not yet stated.

[Rahix]

I have a usecase for parity/framing errors. In profirust (a PROFIBUS-DP communication stack) it would be nice to differentiate between "receiving nothing" and "receiving an invalid character" for error statistic tracking. This is then usually used to help users while troubleshooting communication problems.

In this context, having a clear indicator of "something was received, but it had a framing or a parity error" would be nice.