Pomodoro r2 Timer/Counter Interrupt Figured Out

I was struggling a bit with getting the timer of the ATtiny84 working correctly. After having set it up, setting a prescaler for the microchip as well as a prescaler for the timer itself, it still wouldn’t quite time to 1 second intervals as I thought it should have. It certainly was timing something, as my countdown did display, and the prescalers were working, because changing those changed the timing of the countdown, but still it didn’t turn out to be 1 second per interval. It took a lot of reading through the datasheet to solve this issue.

So, specifically, my timer ran just a little slower than 1 second. I took a stopwatch app on my phone and timed out 20 intervals (i.e. LED changes), and found that it ended up being 17% slow. Not a staggering amount, but counting for that over 25 minutes it would end up being over a minute slow per pomodoro count. Given that my current firmware somewhat skips over the first count, it would still end up okay, but that’s just sloppy programming!

The solution to my problem lay in reviewing step-by-step the process of the timer as described in the datasheet. Reading though the Timer/Counter Interrupt Mask Register 1 section explained what the Timer/Counter1 Control Register A did, which helped me relate the Timer/Counter Register to the Output Compare Register A. As you can imagine, it was a lot of juggling of registers and bits. However, going through that step-by-step helped me track down my issue. As it turns out, the Compare Match A Interrupts (OCIE0A in register TIMSK0) was dependent on the bit setting of WGM01 in register TCCR0A. In other words, I had set everything up to compare the timer to the value I’d set, except for the actual register that tells the chip to make that comparison. No wonder it didn’t work!

Reading up on the datasheet also explained why I got the exact mistimed count that I did. Without setting WGM01 in TCCR0A, the timer is in “normal” mode, where it doesn’t compare but just checks to see if its in overflow. Overflow is defined as maxing out the register at oxFF in hexadecimal, or count 256 in decimal numbers. I’d set up the prescalers so that the timer was just over a second for a full count (so 256 cycles took 1.045 seconds), which is why I needed to compare it not to 255 but to 243 cycles: 8,000,000Mhz / 32 (prescaler) = 250,000 cycles/sec. 250,000/1024 (timer prescaler) = 244.14 cycles/sec. However, we start counting at 0, so it’s a count of 243 that’s almost exactly one second. As a result, waiting for the overflow rather than the compare made my timer slow.

This leaves me with one last thing to figure out: the pause button. Last time, I mentioned that buttons are, apparently, usually polled instead of checked via interrupt. Furthermore, they are usually debounced in firmware rather than hardware. After reading more, I now know the reason for the latter. Even though the components needed for debouncing are quite cheap (we’re literally talking a couple of cents here), production rules are usually made by large companies who produce tens of thousands of boards per product. So, an addition of even a few components of a couple of cents still add up to a hefty cost when multiplied by thousands to millions of components. On top of this, each component added adds a production step, as they will need to be mounted to the board, again leading to higher costs. Firmware, on the other hand, is programmed once (hence only paid for once), and can be copied indefinitely. In my case, this just doesn’t apply, so why not hardware debounce if that meets my needs?

The other problem lies with checking the functions. In my original design, a short press pauses, but a long press reset a timer. I did that using the millis() function in Arduino, which I now realize was just a timer used to count milliseconds. However, that also involves polling that at a regular interval, whereas my goal was to have the microchip sleep most of the time to save on energy. I’ll have to figure out how to approach this. I’ve read two completely opposite points of view on this: a chip can be set to work slowly, sleeping most of the time to save as much energy in sleep states; alternatively, the chip can be set at a high frequency, so when it is awake, it does whatever it needs to as quickly as it can, so it can return to sleep as quickly as it can. Right now, I don’t know what’s best, but it’ll be fun to figure that out.

Leave a Reply

Your email address will not be published.