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…
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.
I was looking for information to help me decide which servos to buy for the legs; wondering about torque and cost and whatever when I followed a link to the Lynxmotion site and came across the documentation for their SSC 32 servo controller. Although I’d looked at their PC based control software that drives this servo controller I hadn’t seen the docs for the controller itself. It seems that it has most of the features that my controller has, including the ‘move multiple servos so that they get to the end at the same time’ command that I’m working on now.
Some of the new commands that I have planned for the servo controller will require that I load and save persistent settings from the ATMega’s eeprom. Having spent a little time looking at the example code in the datasheets it seems that you have to disable interrupts to safely read and write the eeprom. It’s not a problem to have interrupts disabled whilst I read the settings when the processor boots up but allowing new values to be written back to the eeprom as the result of a serial command will be problematic given the interrupt driven nature of our PWM pulse train.
This is the source code for the latest version of the 64 channel servo controller as detailed here. This is an ATMega168 version of the controller that was originally developed for the ATtiny2313 but which was ported to the ATMega when I ran out of memory on the ATtiny. The schematic required is similar to the one for the ATtiny2313, I’ll produce a new one for the ATMega168 when I get some time.
The new 64 channel ATMega168 serial servo controller accepts the following commands. All successful commands are echoed back. Parameters are validated and errors are indicated with an error response of [0xFF] [badParamIndex] [Command echo] where badParamIndex is a 1 based index of the parameters in the command and indicates which parameter failed validation. Set Servo Position [0x41] [servo] [position] - This command operates in the same way as the standard SSC compatible servo command that the original servo controllers supported.
Due to work pressure and then holidays and then more work pressure I had to take a break from the servo controller for a couple of weeks. Most of the code changes that I had previously been discussing have been implemented and I’m now in the process of testing an ATMega168 version of the 64 channel servo controller complete with new style commands! Since this version of the servo controller uses a custom serial protocol and since it can send unsolicited serial responses back to its controller I needed to write a new PC based control program to test it with.
The new functionality in my servo control takes more memory to implement due to the more complex state that we need to maintain for each servo. The simple controller could support up to 64 PWM channels on the ATTiny2313, the more advanced controller can, at the present stage of the design, support around 15. There’s scope to optimise the storage of the expanded 2 byte pulse duration values; they’re 12 bit values and so will fit in 1.
So far the servo controller development has been reasonably straight forward; once various design issues were considered and once I’d got my head around building the hardware and learning AVR assembly language. However I expect that my assembly code has many novice mistakes and that it’s probably not especially idiomatic. I haven’t been writing in the language long enough and I haven’t read enough of other people’s code for it to be otherwise.