Kinetis: hwtimer refactor #3146
Conversation
jnohlgard
added
Type: enhancement
| uint32_t tmp; | ||
| uint32_t cnr = LPTIMER_DEV->CNR; | ||
| uint16_t tmp; | ||
| uint16_t cnr = *((uint16_t*)(&LPTIMER_DEV->CNR)); |
There was a problem hiding this comment.
Is it really better that way? Does it make a difference if cpu compares 32 bit or 16 bit?
There was a problem hiding this comment.
No, it does not AFAIK.
The above was a left over from an experiment when I tested if the memory access width would make a difference. I could not observe any difference other than the CNR not latching unless the write was 32 bit.
Changed back to 32 bit.
|
Addressed comments and cleaned up a little. Replaced some 16 bit vars with 32 bit. |
jnohlgard
force-pushed
the
pr/kinetis-hwtimer-refactor
branch
from
68f9bf5
to
b2945eb
Compare
| DEBUG("cntr: %lu, cmr: %lu, diff: %lu\n", stimer.counter32b, stimer.cmr32b, stimer.diff); | ||
| uint32_t diff = stimer.diff; | ||
| uint32_t cnr = lptmr_update_cmr(diff); | ||
| ++stimer.counter32b; |
There was a problem hiding this comment.
Can you please change it to stimer.counter32b += 1; , just for readability and move the comment from L143:L144 here?
|
@gebart Tested on kw2x, ACK, please squash |
- Use hwtimer_set for hwtimer_set_absolute() - Collect hwtimer statistics with #if ENABLE_STATS - Assembler optimized functions for CNR handling - Correct off-by-1 after counter reset - Defer CMR update from hwtimer_unset until ISR fires
jnohlgard
force-pushed
the
pr/kinetis-hwtimer-refactor
branch
from
e05c9ee
to
65f088a
Compare
|
Squashed, updated the |
|
travis is happy, go |
This PR reduces the number of lost ticks in the Kinetis hwtimer, see #3139
The number of lost ticks is reduced to 14 in a 900 second test run of tests/vtimer_msg, that corresponds to a timer error of less than 0.5 µs / sec. Lost ticks are not good, but at least at this rate the hwtimer_now clock is actually usable.
Note: these lost ticks that this PR is trying to reduce are purely in software, it does not matter if the RTC crystal is slow/fast or otherwise bad, as both LPTMR and RTT was running off the same crystal source during the test and should therefore count up at the same time.