cpu/[msp|cc]430: added peripheral timer driver#3724
cpu/[msp|cc]430: added peripheral timer driver#3724haukepetersen merged 21 commits intoRIOT-OS:masterfrom
Conversation
haukepetersen
added
Type: enhancement
|
Nice! will test ASAP. (you probably need to (void) some arguments) |
|
@kaspar030, any progress testing this? |
|
nope, busy, will do later today! |
|
Works as expected on msb-430h. Can't test on other boards. Do you want to fix the "N" define in xtimer or the msb headers? ACK after that is fixed. |
|
Just fixing it as we speak.. |
Conflicts: boards/msb-430-common/board_init.c
- s/N/NUMOF/ - blacklisted chronos for insufficient RAM
haukepetersen
force-pushed
the
add_msp430_periph_timer
branch
from
08e2f43 to
151dbf9
Compare
|
fixed the xtimer tests that Travis was complaining about and removed the TI legacy header ( |
|
Tested again on msb-430h, ACK holds from my side if travis is happy. |
|
Will test on Z1 and WSN430 now. |
|
Hm, on Z1 with The node seems to run fine for some while and then trigger a lot of interrupts at once, go back to normal mode and so on... |
|
I can reproduce this behavior on the |
|
For the record: very similar pattern on wsn430-v1_3b |
|
same on msb430h. hm, whenever that happens, the actual sleep time goes backwards by around 63k us, which sounds like a 16bit handling issue. |
|
@haukepetersen yes, let me try to rule out xtimer stuff, but it actually looks like that. |
|
yap. Is there maybe some mask define for 16-bit timers that I missed to set for the boards, but xtimer needs? |
|
I don't know if related and/or helpful, but |
There was a problem hiding this comment.
minor: but why did you revert this change?
There was a problem hiding this comment.
propably copy+paste. I tend to use guards without trailing underscores in the files I create...
There was a problem hiding this comment.
No strong feelings, would just vote for consistency and currently we have 36 PERIPH_CONF_H_s and only 6 PERIPH_CONF_Hs.
There was a problem hiding this comment.
I don't care, I can offer you to open a follow-up PR to make them all consistent. Would that work?
|
re-introduced |
Uff, that should seriously be fixed in pthreads. Promise to at least create an issue. ;) |
|
I have the feeling that this somehow loses interrupts, but I can't pinpoint it. I'm on it. |
|
No, my problem is xtimer related. ACK when travis is happy! |
|
nice :-) |
|
Travis is happy -> and go! |
cpu/[msp|cc]430: added peripheral timer driver
|
yay! |
3 participants
To get RIOT ready for the xtimer, here is the low-level timer implementation for all MSP430 based boards. For backward compatibility, all effected boards do now use the
hwtimer_compatmodule.Please note, that the
vtimerwill not work correctly anymore, as it depends on a 32-bithwtimer(while we now only have 16-bit wide low-level timers). But this should not matter much, as the boards run perfectly with thextimer!Note2 (especially @kaspar030): So far there is almost identical code for the
cc430and themsp430fxyz. Especially for some other peripherals, they seem to differ quite a bit, but I am not sure yet to which extend. So the strategy is clearly for now: implement separately and merge again as soon as I have a better feeling for those MCUs - so be patient :-)PRs for other peripheral timers will follow soon...