L'Hexapod: Serial communications issues
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.
I’ve just spent a while tracking down a but which ended up being in my PC based control software rather than in the serial servo controller firmware.
The symptoms of the problem were that my servo controller would suddenly to process random, poorly formed commands. My control software was sending commands correctly but it wasn’t waiting for a command echo from the servo controller before sending the next command. Due to the design of the controller (i.e. the fact that we don’t use interrupts for the serial communication code) if new commands are sent whilst the controller is processing the current command and before it has echoed it then serial data might be lost. This throws the serial command processor out of sync and hence my problems.
Changing the PC control software to wait for command responses before sending new commands has solved the immediate issue but I think I need to have a bit of a rethink about the serial communication design. Right now commands such as the various stop and query commands all do more work after they’ve echoed the command back. Theoretically the PC software could send a new command at that point and this new command might get garbled due to the fact that the servo controller is still processing the previous command and is not processing new inbound serial data. What’s more the whole asynchronous movement complete response system also delays the serial read code.
I guess the best solution is to process the serial data input using interrupts, but that will potentially throw off my PWM generation code as a serial interrupt could be being processed whilst timer interrupt should be running…
