Hey guys.
I think I found a bug in the setPeriod function in HardwareTimer.cpp.
When I run the "TimerInterrupts" example sketch in the Maple IDE on my Maple R3 and Maple RET6, my LED doesn't blink (actually it is blinking so fast I can't see it, but connecting pin 13 to speakers one can hear a high pitched tone). The other timers runs normally, pausing when you press the button.
I also tried running the "LED Blink" example sketch from http://leaflabs.com/docs/lang/api/hardwaretimer.html#using-timer-interrupts. Here I also get really fast blinking (between 1 and 2 kHz I'd guess from the sound), although I should only get 2Hz (not 0.5 Hz as it says in the documentation).
This got me poking around in the setPeriod function, and comparing with the previous one that worked.
Compare the setPeriod function in 0.0.10 with the one in 0.0.9:
https://github.com/leaflabs/libmaple/blob/master/wirish/HardwareTimer.cpp
https://github.com/leaflabs/libmaple/blob/0.0.9/wirish/HardwareTimer.cpp
I think the problem is in these lines (102-103):
uint16 prescaler = (uint16)(period_cyc / MAX_RELOAD);
uint16 overflow = (uint16)round(period_cyc / prescaler);
which in 0.0.9 looks like this (lines 83 - 87):
uint16 ps = (uint16)((cycles >> 16) + 1);
setPrescaleFactor(ps);
setOverflow((cycles/ps) - 1);
I suggest adding the "+1" back to the first line, because otherwise the overflow in the second line will always be higher than 65535, and then actually wrap around to a low number when truncated with (uint16). When entering a number of microseconds less that 65536, we also get a prescaler of zero, which is bad for dividing in the line below, but also for the setPrescalerFactor function, which actually subtracts another 1 before setting the "prescaler", hereby effectively wrapping the prescaler backwards from 0 to 65535 before sending it to the timer_set_prescaler function.
Then I am curious why MAX_RELOAD is defined as 65535 instead of 65536. It makes sense for me that it would be 65536, since that is the number of steps in the overflow counter (rolling over from 65535 to 0 is also a step, right?). But I am not sure that is the way to see it. I can see though in the previous code from 0.0.9 that you also divide by 65536 there: (cycles>>16).
So far I have added the "+ 1" and changed MAX_RELOAD to just (1<<16), and I haven't experienced any other problems with the timers :)
Jakob