-
Notifications
You must be signed in to change notification settings - Fork 153
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
Verify peripheral configuration support inline instead of seperate has_
functions?
#382
Comments
An edge-case to consider are RAZ/WI (Read-as-zero, writes ignored) register fields which do not necessarily have an associated flag bit to check for support. Per the standard one should try to configure these and if they subsequenty read zero (unless zero was written to disable the feature), the configuration failed. An example of this is
A more proper way to achieve this is to read back the |
CC @TDHolmes because of your recent work on |
See above PR. Implementing an |
I don't think the code duplication would be too bad. Just pulling out all of the write logic to In general I agree that this proposal makes sense. We should check as much as possible for the user |
Only possible with features that have their own feature flag field, e.g. |
Ah of course. I read that and then immediately forgot when thinking about this haha. In that case I'm thinking unchecked variants should only be added if someone requests it or there's a clear use case, otherwise be safe and avoid the code duplication |
Throughout the crate I believe most (if not all) register-mutating functions are unchecked, meaning that the crate user should check for support before enabling and configurating a feature. I consider this reasonable for trivial functions such as
DWT::has_exception_trace
andDWT::enable_exception_tracing
but less so for more complex functions likeDWT::configure
andITM::configure
which may enable and configure a whole set of features. For these functions it's not trivial to figure out whichhas_
functions must be called before configuration (presuming they are implemented in the first place).I believe it would be a better idea to verify support in
configure
functions before registers are mutated (and returnErr
if the requested configuration cannot be applied) and offer someconfigure_unchecked
variant when the user knows when a set of features are supported. I'm not sure if we should do the same to the more drivial functions.Thoughts?
The text was updated successfully, but these errors were encountered: