Detours with Arduino Code

“Umwege erhöhen die Ortskenntnis” (detours expand local knowledge) was a common saying of my philosophy professor after he went on a tangent during class.

I love the saying and I know the feeling pretty well – it frequently happens to me when I start to get interested in a topic. I start to research something, then I notice another interesting aspect, then another, and then another, and then… I guess you can see a pattern there. It’s similar to the process Dory experiences when she is trying to do something in Finding Nemo.

The downside are ever-growing, never to be empty reading and to-do lists, the upside is serendipity – I often end up finding and doing something unexpected and the process is often fun (if I don’t have to meet a deadline, that is).
An example would be how I started to read about how coffee is roasted and how I ended up doing things creative technologists do. But that’s a story for another post, I guess. So, back to Arduino code…

The other day I got quite annoyed with the Arduino code that I see online a lot, and I am also guilty of creating myself.
For non-nerds (read: normal people), who don’t know what I am talking about and are still reading: the Arduino is a micro controller which is programmed in C or C++. Unfortunately, the choice of languages is a poor one. Both are fairly complex for novices to master. You can do a lot with them, but you have to know what you are doing. Most Arduino programs squeeze all their behavior into a single function called loop(). And if you want to use the Arduino for non-trivial stuff, the function quickly becomes complex and confusing.
And when I thought: “I should briefly look into this and find a better way,” the detour started.

I did learn C/C++ ages ago (in the third semester of university) and I began by looking up how object orientation should be done on the Arduino. Object orientation allows you to encapsulate the inner workings of things, you might have guessed it already, in so-called objects. Thus it reduces the complexity of your code.
Unfortunately, there were not too many good examples available online. I found one from Adafruit and one from Paul Murray on the Arduino Forum, which I quite liked. The later explains the concept by building a hardware button class.

Only the end of the article threw me off – the class did encapsulate the inner workings of a button all right, but the loop() function was still too complex for my taste, because it was frequently checking the button’s state. Instead of bugging the button how he’s doing, I’d rather be informed by the button itself when something comes up. I realized, I was missing callback functions in the class. So I read about that for a while. My favorite article was by Nick Gammon.

To grasp the concept, I started to write my own button class, combining both concepts. Hardware abstraction classes are of course not a new idea, so I did some research how other people’s solutions looked. I found that other classes did not detect double, triple and long clicks, so I thought I’d try to implement this.

It began with a re-cap of how to write a class in Arduino’s C++ and ended with me creating an Arduino library ([1][2]) available online.
A library contains the class itself, a brief description and some examples and can be downloaded via Arduino’s Library manager. For this some extra files (library.properties and keywords.txt) are needed, and the full package must then be uploaded to github. Thus I learned how to use git, a software versioning tool, to publish my files to github.

And that’s it – pretty straight forward, no?
But I managed to simplify the my loop() functions and built a decent button class, I hope. Plus, I picked up a few things about object orientation, classes, callbacks, libraries and version control.

If you care to take a look at the result, my class is called Button2.
In the meantime, I’ll take a look to see what’s next on my list.
Oh, neat!

And look, over there…