For the software of the Topsy Turvy Clock the natural choice was to use the loader and tools provided by Arduino. This meant the coding would be in C++.
It’s been a long time since I last used this language so there has been quite a bit of re-learning. I have also been warned about the limited resources of the Arduino but I’ve also resisted the temptation to prematurely optimise the code and so far have not had any issues.
When starting out I looked for existing code that would help with my project. I looked at several stepper motor libraries but settled on Igor Campos’s CustomStepper as a base to build my new version. I ended up recoding this rather than subclassing as I found it difficult to extend the class without accessing its internals.
So that the clock could automatically adjust for daylight saving I also added Jack Christensen’s TimeZone library which in turn used the Time library. The Time library has a nice feature in the form of a periodic call back for syncing with a time provider such as a RTC. This means your clock keeps good time without constantly needing to communicate over the I2C bus. The TimeZone libary seems quite elegant but the Time seems more C like with globally scoped functions. As per a lot of hardware drivers there do seem to be several versions of the RTC code for the DS1307 library.
The Arduino platform does seem to have this consistent conflict with the core team writing in a C style and third party hardware providers wrapping up their code in classes.
I looked at some menu classes and techniques but as my UI is very simple I did not need to use them.
I’ve tried to stick with a C++ approach and have designed the software around a series of classes. I would normally use unit testing techniques to aid my development but have yet to familiarise myself with how to do that on this platform.
The stepper motor class provides the interface to the motor and optosensors. The clock class encapsulates the RTC and TimeZone classes with methods to set the time and date. The controller class glues everything together and provides the UI in the form of serial commands. The code uses the String object’s abilities to parse the commands. Setup and loop don’t have much to do, simply repeatedly calling the controller’s run method.
As I was often using the serial port to “print” debugging information the Arduino Micro caused me a few headaches. Because the Micro is a single chip solution, when it resets to load new code it also resets the serial port. This causes two problems, sometimes the port changes and sometimes it fails to be detected at all. The first is fixed by simply selecting the updated port in the menu and the later requires the Arduino IDE to be closed and the Micro to be restarted. My work around was to do some of the development on my Arduino Uno before swapping back to the Micro for testing.
This problem could also be resolved by a unit testing approach as it would mean some testing could be done without hardware. Where this would become problematic is when hardware interdependencies came into effect such as the slotted opto sensor and the stepper motors.
The work in progress code can be seen over at Github.