Clarify description of rtc_isenabled() and standardize behavior on CI targets #518
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
My previous PR, #502, identified some issues with the RTC driver's isenabled() method and added a new test. However, turns out I kinda half-assed it: the test was failing on the targets that I have set up for CI, and I also didn't properly update the documentation.
This PR fixes that problem, at least for the targets I have ready access to. I updated the documentation to better explain the new behavior and updated the target code to fix all the test failures.
Note that there may still be some targets with inconsistent behavior of this function, but I expect to catch those as more targets are added to the CI tests. Also, this function's behavior was never very consistent to begin with, so I am not really sure if this is a behavior "change" as much as a behavior "clarification".
Impact of changes
rtc_isenabled()rtc_isenabled()function now conforms to the new defined behavior instead of (in most cases) only returning true once the RTC time has been set on the current bootMigration actions required
If you were using
RealTimeClock::isenabled()to detect whether the time had been set yet on the current boot, you will need to instead track that with a flag at the application level. (the behavior of this function was not consistent across targets but on many targets it used to have that behavior)Documentation
Code docs updated
Pull request type
Test results
Ran the RTC tests on my six CI boards and they all pass now!