I had a quick look at the schematic I made, and spotted a quick mistake there. I had tied the buzzer to the reset line, as I figured that pin would only be used when reprogramming the ATtiny84. However, I neglected to notice that the pin is an active-low pin, meaning that it resets when the signal is low; as a result, the pin has to be tied high – i.e. the buzzer would be on a constant high line. Whoops! So, that was an easy fix, fortunately.
I don’t have an ATtiny84 yet, but I’ve been testing the interrupts with an ATtiny13. It turns out that there’s a Watchdog function, which is quite easy to implement. I read through a good post on low-power mode for the ATtiny13 which explained it quite well. That post is the third in a series of three, of which the second one also nicely explains timers in general. As it turns out, trying to program it in low-power mode won’t really matter that much for my project.
The basic idea is that the timer is a separate structure within the microchip, that keeps timing regardless of whether the code runs. That’s why it can interrupt the code at any point, freeze it, do its Interrupt Service Routine, and get back to the code. It’s a great way to have a microchip respond to a button input no matter what it’s going, or to have a chip go into low-power sleep mode until it has to do its job (for example, taking a temperature measurement once per hour). The timers work on a microprocessor-level of speed, so we’re talking mHz here; consequently, most interrupts I’ve seen are in the order of seconds. Though my circuit only cares about minutes, I’m going to have to default to waking the chip up every second for a countdown. Still, though, that must save some power, right? Well, yes and no. It saves some energy on that low-power state microchip. And in the meantime, there will be a handful of LEDs on almost constantly – the power usage of the microchip pales in comparison.
Nevertheless, I’m going to reprogram the code to use the timers, and downclock the microchip. Not particularly because it will generate a massive powersave, but because I want to learn and this is quite a simple project to test this out on. Plus, any little bit helps, right? While at this point I could reconsider my choice of LEDs over an LCD screen (considering the LEDs are a big power drain anyway), I don’t think I will. I want to finish the project, and if I keep revising it, it may end up never being done. So, with that in mind, I started testing KiCAD’s PCB builder.
While the interface is somewhat arcane – there’s many options, shortcuts, jargon-filled terms, and so on – the process is actually quite simple. Mostly just a case of dragging a component from place to place, and then clicking along a path to put connections in. After some fiddling, I was easily done. On top of that, I saw that there was a 3D viewer built-in – score! So, this is my current version:
You can see that there was no 3D image for the buzzer, but otherwise I’m quite pleased. I took pin headers as a placeholder for the small putton and switch that I’ll be using in the bottom right. On the left, there’s two pin headers that I used as a placeholder for the battery. My main problem is still that I want a rechargeable solution for power – I just don’t feel like throwing away coin cell after coin cell. So, I figured, this way, for now, I can at least hook up whatever battery solution I end up with. If I don’t install it on the board directly, I might actually just include two notches on the sides of the board for me to slide in a rubber band and hook some battery back on the back.