-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling of parity and framing errors in embedded-io / embedded-io-async #577
Comments
I have the same issue, |
same here! |
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 |
We talked about this ticket in today's wg meeting. The conclusion of the discussion was:
However, only a few people were present, so there may be other ideas not yet stated. |
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. |
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.
The text was updated successfully, but these errors were encountered: