cpu/cc2538/periph/timer overhaul

[hexluthor]

• Use the 32-bit counter mode.
• Apply frequency scaling for non-16 MHz frequencies.
• tests/periph_timer works now.

Tested on boards/cc2538dk. The previous implementation used 16-bit counters and did not work properly.

[hexluthor]

Just expanded the scope of this PR a bit. Added support to xtimer for a negative XTIMER_SHIFT. Now xtimers should work on cc2538-based boards. Specifically, the following tests seem to work, at least on boards/cc2538dk:

• periph_timer
• xtimer_drift
• xtimer_hang
• xtimer_msg
• xtimer_msg_receive_timeout
• xtimer_now64_continuity
• xtimer_remove
• xtimer_reset
• xtimer_usleep_until

[A-Paul]

Hi @hexluthor , thanks for your effort and "rebooting" whole thing. I try to counter check the periph_timer and xtimer_* asap.

Have you noticed #4838 already? Maybe you can take it into account.

[A-Paul]

Couldn't resist and made a quick check with periph_timer xtimer_hang and xtimer_usleep_until (the stinkers in #4729). No hangups!
Congrats. 👏

And, do you mind enclosing the numeric defines in parenthesis?

[A-Paul]

@kaspar030 I would appreciate if you assist reviewing. In particular the xtimer stuff.

[jnohlgard]

The macro names XTIMER_RSHIFT and XTIMER_LSHIFT are easy to understand when looking at the diff in this PR, but I think it can cause confusion in the future ("why is XTIMER_RSHIFT a left shift?"). Any ideas for easier to understand names?

[A-Paul]

@hexluthor, I ran all the tests. One fail.

• xtimer_drift: FREEZES

2016-02-24 16:43:55,527 - INFO # main(): This is RIOT! (Version: 2016.03-devel-600-ge06e7-hedon-cc2538-periph-timer)
2016-02-24 16:43:55,530 - INFO # xtimer_drift test application
[...]
2016-02-24 16:43:55,599 - INFO # sending 4th msg
2016-02-24 16:43:55,600 - INFO # Starting thread 5
2016-02-24 16:43:55,620 - INFO # now=0.095278 (0 hours 0 min), diff=0
2016-02-24 16:43:56,619 - INFO # now=1.095381 (0 hours 0 min), diff=103
/exit
2016-02-24 16:44:16,658 - INFO # Exiting Pyterm

• xtimer_hang: SUCCESS
• xtimer_msg: SUCCESS, timing looks reasonable.
• xtimer_msg_receive_timeout: SUCCESS (after applying patch from tests: xtimer_msg_receive_timeout: remove timer before ending scope #4883)
• xtimer_now64_continuity: SUCCESS
• xtimer_remove: SUCCESS
• xtimer_reset: SUCCESS
• xtimer_usleep_until: SUCCESS

[hexluthor]

@gebart, I agree the macro names aren't great. I'm open to suggestions. Originally I wanted XTIMER_SHIFT() and XTIMER_UNSHIFT(), but that was confusing too, and collided with the already defined XTIMER_SHIFT value. Suppose we use XTIMER_TO_1MHZ() and XTIMER_FROM_1MHZ()?

[kYc0o]

So I can test this PR to ACK but I don't know if @gebart wants to change these macro names?

[jnohlgard]

I don't have any good suggestions for names, but I think XTIMER_SHIFT_TO_1MHZ is better than XTIMER_RSHIFT etc.

[jnohlgard]

needs rebase btw

[hexluthor]

Ok, rebased and I changed the macro names to XTIMER_USEC_TO_TICKS() and XTIMER_TICKS_TO_USEC().

[kYc0o]

I tested periph_timer and all xtimer, with success. Just waiting for travis to ACK.

[kYc0o]

Incredible, travis failed because a signature verification failed... restarted...

[kYc0o]

Done! ACK and go!