This is the AVR Studio project and assembly language source code files for the latest version (v7.0) of my 64 channel serial servo controller.
This is the latest version of the ATMega168 version of the code which includes all of the new servo commands that I wrote about here including the multi-move command and the unit tests that I spoke of here. The controller allows you to set minimum, maximum and startup servo positions for each servo which can be saved into eeprom and used every time the controller is powered up.
The latest version of the serial servo controller is now fully operational (I’ll upload the source code shortly). There are still some bugs that I’m finding but the work I put in to getting the unit tests in place makes fixing these bugs pretty straight forward. Whilst I have pretty much 100% coverage for the simpler serial commands I’ve stopped writing tests for the ‘multi-move’ command now and I’ve switched to “Just in time” testing; that is I write a test in response to finding a bug.
It’s taken me almost a month but I’m finally back to working on integrating the multiple servo move command into the rest of the code. Well, the integration was done long ago, unfortunately the debugging was the bit that was taking up my time.
I decided that putting ‘printf’ style debug output into the routine to attempt to debug it from my PC based control software was just the wrong way to go about finding the problems and so I set off on a mission to finally get some unit testing into my code.
The test code for the serial command processing code for my serial servo controller is turning out to be the largest piece of assembly language that I’ve written. This means that all of a sudden I’m coming across “Relative branch out of reach” errors during the compile. I’ve got to a point where every time I add a test I have shuffled the code to such an extent that several relative branches need adjusting from rjmp to jmp or rcall to call.
The AVR assembly language unit tests that I spoke of last week are going well. I decided to explore the idea of unit testing by writing tests for the easier to test aspects of the serial protocol code and then, as this went well, I decided to write tests for the serial protocol code in order rather that simply jumping to write tests for the code that I know is broken.
As I mentioned yesterday the servo controller project has got to the point where being able to unit test the code would be useful to me. In my day job as a C++ server developer I’ve been using unit tests for several years and most of the code that I write is written in a Test Driven Development style. This works well for me and was one of the first things that I missed when I started to develop in AVR assembler in AVR Studio.
Way back at the beginning of this journey I mentioned the fact that I’d quite like to be able to use some of the development disciplines that I use in my day job during the development of the firmware for my hexapod. Now that I’ve actually written some non trivial assembly language for the AVR I find that I’m missing not having my usual unit tests to support my ongoing development and refactoring.