The simple servo sequencer that I’ve been working on has exposed a bug in the servo controller firmware. The bug is due to stack corruption during movement completion notifications, so it only happens if you use the ‘multi-move’ commands or the delay move command. The problem is that at the end of SerialSendMoveCompletionNotification we jump back to the serial data accumulation loop rather than using a ret to return… Since we enter SerialSendMoveCompletionNotification via a call rather than a jump we are failing to balance the stack and so eating two bytes each time we call the function.
Whilst playing around with my servo controller I realised that the power used by a servo goes up considerably when it’s under heavy load (such as when it’s pressing against the table and still trying to move). I can, potentially, get an idea of this load by measuring the current that each servo is using and using this feedback somehow. I’ve yet to work out how, but at the very least it could be used to protect the servos against overloading; if the load gets above a certain threshold then stop moving!
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.
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.
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.