-
Notifications
You must be signed in to change notification settings - Fork 221
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
Use set_interrupt_handler()
everywhere and consider creating a trait
#1489
Comments
related to #1478 While implementing the changes to the constructors it also felt not like a very nice change API wise The good thing about the ctor taking the interrupt handler would be the user can be sure nothing will change (well - we have unsafe API to change it ... so it's not a strong gurarantee). Besides that, consistently having a Not too sure about having a trait for that - it won't hurt but in most cases the user code will need to know exactly what interrupt handler it's dealing with - but we can add such a trait and see how useful it is in the end |
In the case of PARL_IO and LCD_CAM where the driver splits in two, I think these two are stuck with c'tor way since both drivers share an interrupt. |
I agree, plus it's generally quite easy to spot when it's changed by adding a log statement in
|
Imo after some time playing with it, the constructors taking
Option<InterruptHandler>
are not that pleasant to use. I think it would be better if everywhere was consistent and usedset_interrupt_handler
. I think having this in a trait would also be good for creating abstractions over this.The text was updated successfully, but these errors were encountered: