The More You Make, the More You End Up Making

Creativity has always been interesting to me, because I don’t see myself as a creative person at all. In building games, I always tended towards making the most efficient rather than the most beautiful structures. Professionally, my greatest strength is reducing the complexity of problems to more solveable issues and helping to guide others to move towards solving them. Artistically, I’ve never been able to do much at all, though I’ve tried calligraphy, playing the violin, drawing, and so on. Language seems to be my best creative skill, though not for fiction but rather for communicating clearly. All in all, I’d describe myself as quite uncreative.

One of my main issues would always be the difficulty of thinking of new ideas out of nowhere. It’s so impressive to me how somebody could look at a blank canvas and just decide what to do there. However, now with electronics, it took me just the one big project to learn the basics of electronics, and I’m starting to get more ideas. I’d run into tiny inconveniences and thought: surely, I can spend way more time solving this miniscule issue than I’d gain by just working through it? And so projects were born. Currently, I have the following ideas clunking around, with no specific timeline for when I’ll actually be working on them:

Hamstercage Lights

My current main project is to install RGB lights in all three levels of our hamstercage build. It’d both simulate a circadian rhythm for whenever we get our new hamster, and would have a manual override for when we need light. My main posts on electronics are all about this, so there’s not much new to report there.

Countdown Timer

This was inspired by the Pomodoro timer, as it’s somewhat related but for a completely different purpose. The Pomodoro timer just counts down in small half-hourish increments, to organize working time and to help remind me to take regular breaks. The Countdown Timer was born because there’d be several moments where Tracy and I are working towards a larger goal with a set deadline, such as when we originally moved over here; conversely, there’s also smaller deadlines, like deciding how much time we have until our groceries get delivered. Again, why use just a mobile phone timer when you can massively overengineer a large LED display or 7-Seg display and program it to display days, hours, minutes, and seconds?

Binary, Hexadecimal, Decimal Converter

While I was programming the Pomodoro Timer in C rather than Arduino, I started using binary and hexadecimal numbers more often to directly address memory. In particular, I’d want to set a whole register to specific bits in one go, and using hexadecimal just seems cleaner to me for some reason. What I’d end up doing is going through a datasheet, checking all the right pins for an 8-bit register, and then using a converter online to figure out what the hexademical is for that binary number. Why accept anybody else’s very convenient solution to a self-created problem when I can make it entirely more complex by spending more time? I could just make a small device that shows the same number in decimal, binary, and hexadecimal, and have several knobs or buttons so that I could change each number and the others would automatically change with it.

Bonus: Taglines For the Blog

As I was writing this, I just kept coming up with additional taglines for the blog (huh, additional task: figure out if I can have rotating taglines). Here’s a selection of my favorites:

  • Answering questions nobody asked;
  • Solving problems I created myself;
  • Solving problems nobody has;
  • Creating problems, then solving them by creating two new problems;
  • Breaking things by fixing them;
  • Fixing things by breaking them;
  • Finding out things nobody cares about;
  • Championing pointless causes;
  • Finding a problem to every solution;
  • Putting the “me” in “meaningless”.

Pomodoro r2 – Update 5

I figured that my design was pretty much as done as I could make it, so I posted it on /r/PrintedCircuitBoard to see about getting some feedback. As always, the electronics subreddits tend to be quite wholesome and education, and full of supportive people willing to help out. Thankfully, they gave me a lot of good feedback, as you can see below:

The Reddit thread where I got my advice

I was happy to learn that KiCAD automatically takes thermal relief for pads into account, as before this thread I had no idea what this was. The other major thing I learned was that there is no reason not to increase trace thickness if you can. And, finally, I learned that there was such a thing as a decoupling capacitor to smoothe out power delivery to a microcontroller, and so I added one (and after advice moved it closed to the microcontroller). That all resulted in a slightly changed design. Furthermore, I solved my issue with the footprints by simply taking a digikey footprint directly from a component I am intending to buy, so that the problem solves itself. I am very excited to come to a close to this project, and seeing it in action!

An update of the board based on feedback from Reddit.

FreeCAD Modelling

So, today, I made my first thing in FreeCAD. When I was testing out some footprints and components for the Pomodoro Timer PCB, I noticed that none were exactly the type of buzzer that I had. Seeing as how my buzzer is pretty much a simple cylinder, I figured it was the perfect object to try and model in FreeCAD. In the end, I’d end up both with a working 3D model to use in KiCAD, as well as some basic experience with FreeCAD.

After quite some fiddling to get things working, and some initial experiments, I finally produced the part in 3D with exact measurements:

A FreeCAD model of the buzzer that I use

Importing that into KiCAD was actually super easy. There was literally a button to just locate any type of .step file and import it as the 3D model for a part that I had selected. So, happily, I put that part on my board. And, to my surprise, it unveiled a hidden error:

The pins didn’t fit!

When I checked the fit of the part, I could see that the actual pins didn’t fit! That sure would have been an issue had I ordered the PCB! I measured twice, and then another time; I checked my measurements in FreeCAD, and everything worked out well. The only outcome could be that the footprint in KiCAD wasn’t correct. Good thing to catch at this stage.

Pomodoro r2 – Update 4

So, I’ve reworked the PCB into what I expect to be the final revision. I eventually decided to add the coin cell battery holder on the PCB itself after all, because it would be a little fiddly to add a holder for two AAs on the back. I’d have to either mess around with glueing it on the back (and making sure that the PCB matches the size), or figure out some kind of screw mounting. Since I don’t have a proper glue gun yet and project box making is something I still have to learn, I figured this was a decent enough solution after all on the level that I’m currently at.

The PCB with components added. Apparently, there’s still no buzzer 3D image, despite it just being a squat cylinder.

As you can see above, the result of adding the battery holder is that the entire PCB is now a little wider and less high, as I shuffled components around slightly. Another thing I noticed was that the pins of the ISP had no significant marking for orientation. I had a look at how it was marked on my USB programmer and noticed that this was done on the back (probably to save space), and that seemed like a good practice to follow. All in all, I’m quite pleased with this final design. Before I do go ahead and order it, I do want to test it out on a breadboard; after all, you never know when you’ve made some silly design error.

So, next step will be to order the components. While waiting for them to arrive, I can rewrite the code already to fit the ATtiny84, so that I can test it as soon as everything is in.

Pomodoro r2 – Update 3

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.

A circuit schematic for the Pomodoro timer, showing an ATtiny84 linked to a number of LEDs, an ISP programmer, and a buzzer. The schematic indicates the whole set is powered by a 3-volt battery.
Figure 1: A slight adjustment to the schematic

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.

Pomodoro r2 – Update 2

I’ve reworked the schematic to include the ATtiny84, and decided to just put a switch in there for the audio. After all, it either needs to attract your attention, or it doesn’t. There’s little sense in dimming it. If needed, I can always finagle a resistor in there during prototyping to check.

A circuit diagram showing the schematic for the second revision of the Pomodoro timer. It is a tangle of wires and components.
Figure 1: Pomodoro Timer, Rev 2.

I’m not particularly happy with how many lines cross in this schematic, but overall I still think it’s fairly legible. This time, I made sure to include a good footprint for each component in KiCad as well. I hope that’ll help me construct a good PCB later on, if I choose to do so. The one component I was struggling with a bit was the battery. I want to include it on the back somehow, but I’m not sure how. I’m pretty sure I can’t just glue it to the back (I mean, can’t I?), so I’m still thinking what to do about that.

Either way, it’ll be time to order some components soon for this build. In the meantime, I can look to adjusting the programming.

Pomodoro r2 – Update 1

Today, I did some research on my Pomodoro revision 2 specifications, and have come to some valuable conclusions. The main one being that my idea to control the brightness of all the LEDs via PWM, sadly, won’t work. Apparently, to use PWM with timer interrupts on an AVR, you need to use dedicated output pins to do so. When exploring the possible μCs that I could use to rework the Pomodoro timer, I settled on the ATtiny84. That μC has just enough pins, belongs to the AVR family, so my program will need minimal adjustment, and I have a fairly good idea on how to downclock it to save power. However, it only has four possible pins to use for PWM, as you can see below.

A schematic showing the pinouts of the ATtiny 24/44/84 family of microcontrollers. Each pin has an overview of all its functions next to it.
Figure 1: The pin-out schematic for the ATtiny84

Now, to be fair, I don’t even know exactly if all four can be used equally for single PWM signals, or if they need do be used in pairs. Regardless, even if they could all be used, that would still leave me one short even if I just wanted to adjust only the timing LEDs. So, easily said, I’ll scrap that off my list; it was an optional feature in any case. That makes for the second feature to be scrapped (I already concluded that the LCD screen would raise my voltage requirements).

I’ve also reconsidered my choice of the coin cell battery, opting instead for two rechargeable batteries. Firstly, I want to move towards more rechargeable power in any case (sustainability is important to me), and this offers me an easy way to do that without immediately having to learn about USB charging in a project. While I want to learn about that, it seems a little overkill for this project. Plus, I figure that including the battery holder on the back of the board somehow may actually provide it with something of a stand.

My first experiments with the volume control for the beeper were successful, but not particularly satisfying. Using a potentiometer, I could adjust the volume; however, it took so little resistance for the beeper to mute, that most of the potentiometer was wasted. I’ll have to test out a range of resistance values to see what makes a relevant value of potentiometer to use. If I can’t find a satisfactory value, I may also just use a switch to make a mute button. I mean, it’s either there to attract your attention, or it isn’t, right?

That leads to the following update to the feature list:

  • Include a 3v coin cell battery; and
  • Include 2 1.5v rechargeable batteries; and
  • Rewrite the program to run off a type of ATtiny an ATtiny84; and
  • Rework the program to use timer interrupts.
  • Change the LEDs to a single LCD screen; and
  • Add a volume control for the beeper; and
  • Add a brightness control for the lights.

Pomodoro r2

I didn’t quite feel settled with my current Pomodoro project. I’d worked up the prototype, and I’m happy it works (despite it being sloppy), but I also think there were several points for improvement left. Or, at the very least, it just didn’t feel done. I figure that the minimal specification to call it a working prototype is to have a battery included, so that it is fully self-sufficient, rather than it is now (which requires either hooking up a battery ad-hoc, or connecting it to USB via the ISP programmer). As I was brainstorming what I wanted to do with it, I came up with the following list:

  • Include a 3v coin cell battery; and
  • Rewrite the program to run off a type of ATtiny; and
  • Rework the program to use timer interrupts.

Now, I thought before of changing the μC around, but at the time, I wasn’t really sure of the what and how. Thankfully, thanks to some helpful YouTube videos, now I do, and it seems reasonable to rework the schematic to not waste the full potential of an ATMega328p on a program which needs about half of the pins. A major thing I learned from the Assembly tutorial is that you can drastically reduce power consumption by working with timer interrupts rather than using a sleep function. Considering I want the project to become more portable, getting the most out of the 3V cell seems like a great idea.

As I was thinking of those, I thought of a few other options that might be interesting. I separated these, however, because the ones in the first list are what I’d consider necessary to call the project done, these would be interesting additional features to add:

  • Change the LEDs to a single LCD screen; and
  • Add a volume control for the beeper; and
  • Add a brightness control for the lights.

The first would be cool, though I’m not sure if it will fit the project. The major issue with it is that a very cursory glance of LCD screens seems to imply that they need a 5V power source, and my intention is to keep the project small, light, and to get as much as I can out of the LEDs. While I want to get an LCD screen and play around to learn about I2C, that may be a thing for a later project.

The other two, however, shouldn’t be too difficult. The beeper I have on there is quite loud, which is good, but I can imagine there’s occasions where I’d want a more subtle notification (plus, my wife will be grateful for less noise too). I could either just install a slide switch to turn it off or on, or perhaps I can put in a potentiometer for more fine-tuned control. The latter will take some experimentation, which will be fun in and of itself.

The brightness control is something that I’d also want to experiment with. Clearly, having a potentiometer for each individual LED would be needlessly complex, let alone that it would result in inconsistent brightness of LEDs. Rather, I would want to handle that directly from the μC. Now, I’ve been reading a bit about PWM signals, and that would seem to fit the bill. Given that my project uses 11 pins (9 LEDs, a buzzer, and a button), adding power and ground, means I have to use a DIP-14 package; i.e. there would be one pin open. What I could explore is if I can use a potentiometer there to control the μC PWM duty cycle. Not only would that mean I can control the brightness, but unlike using resistors to do so, this method would actually also save power and match my original goal of having a low-powered portable device.

I know nothing about PWM aside from the broad concept, so that would be an interesting thing to learn about. That would mean that revising this project would teach me about both timer interrupts and PWM signals – score! On top of that, I do enjoy how that would make the control of the device consistent: a single push button to control pauses and resets, and two potentiometers to control the amplitude of the output (whether soundwaves or lightwaves).

If I only manage to add the battery and have it at that, I think I’ll leave it as a perfboard prototype. If I do the other points as well, I think I’ll see about designing it as a PCB, and having it manufactured somewhere to get a final product. That’d be bonus points for practicing PCB design and soldering!

My First Makefile

Following that AVR Assembly tutorial I’ve been mentioning recently, I’m finding myself compiling and flashing programs to the ATtiny13 quite frequently. So, after doing that twice, I was done with repeating those steps over and over, when I could just automate that part. My first instinct was to use a simple Shell script to put the commands in, but Linux wouldn’t be Linux if somebody hadn’t already run into and solved that very same issue. So, today I learned about Makefiles.

The way I understand it, make is a program designed help in compiling – it checks whether any source files have changed and, if so, compiles them again. In programs of the size I’m writing, that’s really a negligible advantage, but I can see with larger programs that more than a second to compile having to wait over and over can get tiring quickly. The more interesting part for me is that I can use it to immediately say “flash this to the ATtiny13!” and the makefile will take care of the configuration of the commands to compile and send it. Right now, I have the following file, which I’m sure will expand as I learn about makefiles and how they work:

MICROCONTROLLER = attiny13
PROGRAMMER = usbtiny
INCPATH = /home/nextcloud/lib/avra
SRCFILE = 5_fast_pwm.asm

$(SRCFILE).hex: $(SRCFILE)
        avra -l $(SRCFILE).lst -I $(INCPATH) $(SRCFILE) -o $(SRCFILE).hex

flash: $(SRCFILE).hex
        avrdude -v -p $(MICROCONTROLLER) -c $(PROGRAMMER) -U flash:w:$(SRCFILE).hex:i

clean:
        rm -f $(SRCFILE).hex $(SRCFILE).obj $(SRCFILE).eep.hex $(SRCFILE).asm.lst

Right now, the filenames it creates are a little ugly (“5_fast_pwm.asm.hex”, for instance), so I’m sure I’ll learn how to deal with that better in time. One of my favorite features is the clean command, though. This way of doing it ends up with me having a lot of cluttering files in there, and having one command in the same set to clean it is great.

Pomodoro Prototype Soldered

After the last failures of trying to bridige connections using a tinned wire, I spent some time browsing tutorials on soldering and point-to-point connections online. Most were not that useful, but I ended up finding one handy tutorial that showed a decent way to do wiring on the copper layer (sadly, it was hard to find and I didn’t save it, so I can’t retrace it right now). So, I went back to my perfboard and tried to solder again, resulting in the wiring you see below.

So, it’s not the cleanest of jobs, but it gets it done. Because I didn’t have any more connector pins of the right size, I couldn’t solder another ISP interface on the board; hence, there’s that odd gap in the components there. Secondly, you can notice a burn or two on the wires on the underside – I had to change soldering around a time or two, and wasn’t paying too close attention to my iron placement, resulting in a little melt right there. Lastly, in the topside picture, you may notice that the three small pomdoro lights aren’t lit up – tomorrow, I’ll have to track down the issue with my multimeter.

A last thing I noticed when testing it out is that there’s an odd bug: there’s a minute gap between every state change. So, once it runs through 25 minutes in one pomodoro, it waits a minute before it initiates the 5 minute pause. I’m sure that’s just a little bug in the software. Of course, when I was testing it, I tweaker the timer to count in seconds rather than minutes, to see all the state changes. Clearly, that also obscured the state-change bug, as it seemed a natural delay. However, now that it’s a minute long, it’s far more noticeable an error.

I’m quite pleased. Even though the soldering is sloppy, I learned so much doing it that I’m pretty sure I can do a much better job next time. Furthermore, it was quite relaxing to do all the soldering. And, lastly, I learned so much doing this, that I’m looking forward to my next project. I’m not too sure what it’ll be, but I’m sure I’ll come up with something soon enough.