embedded-hal: [RFC] Should we add methods to clear errors?

I’ve just discovered that the nice errors we may create in HAL implementations have no standard way to get cleared which often means that the peripheral is stuck in that error.

E.g. If we use a hal::serial:Read implementation we may get an Error::Overrun reported by the implementation but without clearing the error flag in the MCU peripheral, any consecutive calls will return the same error over and over again.

There’re three ways to address this:

Have each HAL implementation create their own custom method to do this
Automatically clear the error in hardware before returning it
Add a method to the HAL traits allowing the user to clear errors

2.) and 3.) have a set of pros and cons attached to them so I’d like to feel public opinion on this.

CC @japaric @hannobraun @thejpster @astro @ilya-epifanov

About this issue

Original URL
State: open
Created 6 years ago
Reactions: 2
Comments: 15 (10 by maintainers)

Most upvoted comments

While I prefer 2, I wouldn’t mind 3 either. However, I think it’s important to be consitent. If 3 is chosen, but resets are also done automatically by some crates, I see some potential issues.

I write a crate but forget to call reset on one of my errors. However, I only test on hardware with an implementation that auto-reset them. Then my code will appear bug free, but will fail if I run it with another hal implementation.
I write a crate that for some reason relies on flags not being explicitly reset, but the HAL resets them anyway. That might be a tricky bug to track down.

Additionally, as @hannobraun said, sometimes the hardware resets the flags automatically after being read, that would make 3 impossible to implement if it is enforced that resets should be done manually. I can’t think of a case where 2 would be impossible to implement, though I guess it would add some overhead if flags are reset even if the user doesn’t want them to be.

Finally, I think forgetting to reset error flags might be a common user mistake which would also be fairly tricky to track down. Having reset being done implicitly by the HAL, would prevent that issue as long as the implementation is correct.

TheZoq2 on Jun 6, 2018

I’ve thought some more about this. I’m changing my vote to option 3:

@therealprof is making a good point.
An implementation can decide to reset the error on return, and make the reset method a no-op. The approach gives us the benefits of option 2 (user doesn’t have to reset manually), while adding a fallback for HAL implementers that otherwise would have forgotten to reset the errors.

hannobraun on Jun 6, 2018