-
Notifications
You must be signed in to change notification settings - Fork 2k
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
cpu: RTC implementation for STM32F1 #11258
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your pull request. There are some things that need to be addressed. I did only check the fundamental stuff and didn't read the datasheet/documentation required for a full review. So there could be more issues that need to be worked out that I didn't spot during the brief look I had at this PR. I will look into this in more detail when the current issues are addressed.
63f8b3f
to
2a04006
Compare
Oh, I just noticed that the commit messages do not have the format
|
Tested on the blue pill using
|
Since rtt.c and rtc.c both use the same underlying RTC in STM32F1 I think you should add:
under |
Tested on iotlab-m3, it works except in sleep modes where the rtc alarm FAILS to wake up the device. |
I'm able to wake up from stand-by:
I'm unable to wake up form stop-mode:
EDUT: this has nothing to since we are not using LPTIM here |
Might it be missing the EXTI configuration? |
This needs a rebase. |
I rebase branch and fix conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good overall, will give it a whirl on the blackpill.
When I run
|
Murdock found some minor issues but |
Fix this on 5d5357b. Use PRIu32. |
b443f35
to
74ebf14
Compare
Works get_time, set_time, alarm and wakeup after set power mode STM32_PM_STOP
_rtc_disable_alarm(); | ||
_rtc_set_alarm_time(0); | ||
|
||
_rtc_clear_isr_ctx(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you don't need this here either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
_rtc_clear_isr_ctx
?
On other processor efm32/rtc, esp32/rtc and other callback is cleared.
I think clear need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just "because others are doing it" is never good reasoning 😉
The alarm can only be enabled again by rtc_set_alarm()
where those are overwritten anyway.
It does no harm, but it's a waste of instructions and adds needless clutter to the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can drop the _rtc_set_alarm_time(0)
too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See other rtc_clear_alarm(void)
. All contain callback clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lpc2387
andcc430
do not…
But yea there seems to be some strange cargo cult going on.Well keep it if you want.
But the_rtc_set_alarm_time(0)
won't help you if the counter wraps around and_rtc_disable_alarm()
was not working for some reason. (Which would be the only reason why you would want to delete the callback)
I found case.
We set time to 15:20:59, and set alarm 15:21:10. Alarm called.
At cur time 15:21:20 - set time 15:20:59.
Now we have: time 15:20:59. Alarm 15:21:10 (rtc_get_alarm
return). But alarm not called (is disable)
I think that after callback we need clear alarm time!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just "because others are doing it" is never good reasoning wink
The alarm can only be enabled again by
rtc_set_alarm()
where those are overwritten anyway.
It does no harm, but it's a waste of instructions and adds needless clutter to the code.
Ok. I can argee with clear_isr_ctx
. isr_ctx
not visible outside. But alarm time visible on rtc_get_alarm
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm I would have expected rtc_get_alarm()
to return -1 if no alarm is set, but this doesn't seem to be the case.
So returning an alarm in the past might be the next best thing.
IMHO the RTC API needs some overhaul…
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm I would have expected
rtc_get_alarm()
to return -1 if no alarm is set, but this doesn't seem to be the case.So returning an alarm in the past might be the next best thing.
IMHO the RTC API needs some overhaul…
If clear alarm on callback, then test periph_rtc work wrong:
puts("Alarm!");
if (++cnt < REPEAT) {
struct tm time;
rtc_get_alarm(&time);
inc_secs(&time, PERIOD);
rtc_set_alarm(&time, cb, NULL);
}
rtc_get_alarm
- return zero time and next 3 alarm not run.
If rtc_get_alarm
return -1
when alarm is disable (on callback too) - same problem. Alarm run only 1 times. Returned value rtc_get_alarm
not check in test. I think replace rtc_get_alarm
to rtc_get_time
- good things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea like I said, I think the API needs a bit of rework to be less ambiguous.
Anyway, your implementation works and should not be help up over different interpretations of the unclear RTC API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on blackpill
board, code looks good.
The semantics of how rtc_clear_alarm()
<-> rtc_get_alarm()
should behave are ill defined, that shouldn't block this PR though.
Implement real time clock for stm32f1.
Tested on bluepill board.
Use tests: /tests/periph_rtc and /tests/periph_pm
Alarm can wake up board with command "unblock_rtc 0 30" after command "off" or "set 0".
set_alarm work fine