L'Hexapod: Fundamental design flaw in the servo controller code
This article was previously published on lhexapod.com as part of my journey of discovery into robotics and embedded assembly programming. A full index of these articles can be found here.
In my opinion there’s a fundamental design flaw in the both the 8 channel and the 64 channel servo controller firmware that I’ve presented. Both allow the serial data handling code to take priority over the PWM generation code. This means that there is no way to guarantee that the PWM generation code will produce a perfect pulse train in the presence of configuration changes being sent to the controller via the serial port. The problem is that although we were very careful to measure the clock cycles taken by the PWM code as it runs so that we can be sure that we’re generating the correct pulses we then allow the arrival of serial data to interrupt the PWM code and throw a random number of operations into the mix thus disrupting the timings. This may cause a pulse to be longer than it should be and will also slightly shift the refresh rate.
I realise that it’s actually pretty unlikely that the timings will get thrown out too much by the processing of the serial data as it stands but it may become a limiting factor as the commands exposed by the serial interface become more complex and require more operations (and therefore time) to accomplish their work. If the pulse lengths get extended significantly by serial operations taking place whilst they’re being transmitted then this will manifest itself as a twitching in the servos.
Because of this I plan to redesign the code to use a timer interrupt to do the PWM generation work and to use polling in the main processing loop to deal with the serial data. Essentially I’ll be turning the current code on its head… This means that the PWM generation will always have a higher priority than the serial data processing and so, assuming I get my timer interrupt and resulting PWM generation code correct this should mean that the PWM pulse train will be rock solid no matter how much work we need to do in the serial data processing code.
Or so the theory goes… Right now the servo controller code seems pretty robust and I haven’t noticed any twitching when under heavy serial data load but who knows…
