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.

I’m in the process of integrating the stand alone code that implements my ‘multi-servo move’ command and the rest of the controller. It’s harder than it should be, probably because I’m not experienced enough yet with assembly language not to have made some school boy errors. Once again I’ve run out of registers, mainly because I’m trying not to have to push stuff on the stack that often. I’ve been juggling with the limited number of registers and up until now it’s worked but…

The work on turning my excel spreadsheet into AVR assembler code which can move multiple servos to arrive at their target locations at the same time is proceeding well. I have the required code operating in a stand alone environment in the simulator and all I need to do now is merge that in with the rest of the code… Once that’s done my servo controller is complete and whilst I already know that there are at least two further versions in the pipeline I expect I’ll move onto something more before working on them.

The final command for my serial servo controller is the most complex. The idea behind it is that with a hexapod leg you will want to be able to move the leg to a new position where the new position requires all three of the servos that manage the leg to move to potentially new locations. Ideally you want the “foot” to arrive at the final resting place in such a way that all of the servos complete their moves at the same time.

Work on the latest version of the serial servo controller is going well. I’d accumulated a pile of random nice to have ideas, some of which then necessitated some other ideas, and then there was the one must have command (the one which moves several servos to new positions over time and ensures that they all arrive at their final resting places at the same time). Of course I’ve worked on some of the nice to haves rather than dealing with the final ‘must have’ command that I need before I can move on to writing some gait controlling software to move multiple legs in sequence…

Having discussed my serial communication issues on AVRFreaks I’ve decided that I need a new design for the servo controller. My current design is very successful in doing what I set out to do, which was to give priority to the PWM generation aspect of the code. We’re generating a rock solid PWM signal. Unfortunately this is at the expense of the correctness of the serial communications and that just isn’t right (although the original code had these same serial comms problems too!

I posted a question about my serial communications issues over on AVRFreaks and so far the answers have been pointing in the direction of including some form of formalised flow control. This makes sense. I’ve yet to decide if hardware flow control in a RTS/CTS form or software flow control such as Xon/Xoff would be best…