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/efm32/timer: add support for LETIMER #13357
Conversation
Sorry I didn't notice the duplication. I did this some while back and I didn't check recently enough to make sure it was still undone. Two days. That's some coincidental timing. |
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 in a first review run, with some comments.
I don't know the PM layer well enough to say much there.
Tested so far with the micropython example on an stk3700, will later run more (especially timer-related; which of tests/* are generally recommended here?) on this board and the sltb001a.
LETIMER_IntEnable(tim, LETIMER_IEN_COMP0); | ||
break; | ||
case 1: | ||
LETIMER_IntClear(tim, LETIMER_IFC_COMP1); |
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 straightforward enough, so take this more as a question of curiosity rather than a reviewer comment: Is this covered anywhere in tests?
Concerning testing: I've run the periph_timer test as With |
Correction:
I've tried stepping through the individual variants, but failed to find a precise culprit that way. I had suspicions about the power manager briefly, but even without the top commit, the test fails when EFM32_USE_LETIMER=0. |
In happier news, I've tested this with the sltb001a (programming which is a pain for different reasons: an openocd 0.11 would be direly due). With the default (EFM32_USE_LETIMER=1) setting, it passes tests/periph_timer, and builts micropython with time.sleep() just fine. |
Whoops, very sorry for the trouble. I just pushed a fix for that. It helps a lot if you actually start the timer... |
Yes, that makes both (One could argue about the necessity to keep the prescaler running, but when it runs I figure it contributes little to the total power consumption; that can still be tuned later.) |
Sorry for the delay. I finally made the drive to Ikea for a Tradfri platform I can test on. I'll get back to this soon. |
I gave this PR a quick test on the STK3600, SLSTK3401a and SLSTK3402a and that seems to work. I tried the xtimer example and some xtimer tests. I think, with Kconfig, we can make the whole LETIMER even optional (as an optimization), just like I did with the LEUART driver. But that is definitely for later. |
@benemorius The requested changes are small. Feel free to rebase + squash. |
e3a095a
to
79e944b
Compare
I guess I didn't recall travis was that stringent on documentation. I'll get that fixed up soon. |
79e944b
to
181e983
Compare
Nevermind, I just botched the doxygen while adapting for #13900. It should be good now. |
@benemorius I think that part of your last commit should be squashed with the first commit (that whole |
181e983
to
c463af9
Compare
c463af9
to
754d790
Compare
Rebased to include the new CI checks. |
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.
Code looks good and from what I gathered this works - I think this PR was simply forgotten.
This PR broke
|
@fjmolinas I'm confused so far. Is this with Could this have anything to do with LETIMER being countdown-only and therefore having the value inverted when read and written? |
Its the default, I think that is |
* @{ | ||
*/ | ||
#ifdef EFM32_USE_LETIMER |
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.
This check is strange, since it uses #Ifdef
if 0 or 1 this statement will evaluate as true.
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.
Will this be enough to fix the timer on slstk3402a
?
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.
hmm no, something else must be off..
* @{ | ||
*/ | ||
#if EFM32_USE_LETIMER |
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.
IMO IS_ACTIVE
should be used here.
if (!(tim->STATUS & TIMER_STATUS_RUNNING)) { | ||
pm_block(EFM32_TIMER_PM_BLOCKER); | ||
} | ||
TIMER_Enable(timer_config[dev].timer.dev, true); |
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.
Toggling the prescaler timer fixed the issue for the test.
@benemorius can you take a look at 32e112d in #14780. That fixed the issue for me. |
Contribution description
This PR adds support for low energy timers to efm32. The implementation supports one LETIMER running at 32kHz which (IIRC) is a limitation imposed by the peripheral hardware.
Testing procedure
Compile with
CFLAGS="-DEFM32_USE_LETIMER=1"
and confirm that the letimer works as intended and withCFLAGS="-DEFM32_USE_LETIMER=0"
and confirm that the regular timer still works as intended.