One of the problems of moving from the simple three byte SSC style control system to a system where we can do clever things with multiple servos at once is that the data required to do these clever things is bigger than the data required to do the simple things. See here for the details of the new control data structure. The problem with data that is bigger is reading or writing it atomically (that is, ensuring that our multi-byte data structures are in a consistent state at all times).

To be able to implement the new commands for the servo controller I need to adjust the data that we use to control the servos. Right now we have a single byte per servo and that byte contains a value between 0 and 254 which represents the length of the pulse sent to the servo. To be able to implement the delayed or progressive move command we’ll need to know the current servo position and the desired servo position.

I now have an easy to extend PWM servo controller and the next job on my list of things to do is extend it so that it supports the functionality that I feel I need for correct control of my hexapod’s legs. As I mentioned here, I’d like to be able to tell the servo controller to move a group of servos to a particular set of positions so that they all arrive at the same time and, the movement is incremental and the movement can be stopped at any point in case a leg sensor detects an obstruction.

The 64 channel serial servo controller that I’ve been developing works pretty well for me but most of my development and testing was done in the AVR studio simulator. Once I actually started working with my hardware again I noticed a slight problem. Although my servo controller was operating to spec my spec was wrong. The problem is that the data sheet I have for the Hitec HS-422 servo states that it requires a pulse length of between 900us and 2.

Here is a schematic for a 24 channel version of the ATTiny2313 servo controller. You can expand the number of channels up to the full 64 by adding additional CD74HCT238Es where each additional MUX chip is connected to the next available pin on port b. ATTiny2313-24ChannelServoController.png The schematic, in Eagle format, is here: ATTiny2313-24ChannelServoController.sch and a potential board layout is here: ATTiny2313-24ChannelServoController.brd These were produced with Eagle and I don’t think I could have worked out how to use Eagle without reading Build Your Own Printed Circuit Board by Al Williams.

The time has finally come to put all of the code from the last three parts of this article together to form a complete serial configured, 64 channel, PWM servo controller for the ATTiny2313 and several CD74HCT238Es. Here’s a recap of where we are and how we got here: In part 1 I put together some basic PWM generation code that uses the 16-bit Timer1 to generate a rock solid PWM pulse train from some pulse duration data.

This is part three of a series of articles about the servo controller that I’m building for use in the hexapod robot that I intend to build. The first two articles in the series have presented the timer driven PWM generation code and the code used to take the configuration data that is managed by the serial port protocol and convert it into the data that is needed by the PWM generation code.

In part1 of this timer driven PWM servo controller I built some code which uses Timer1 in the ATTiny2313 to generate 64 PWM signals. The code in part 1 worked from hard-coded dummy data. The code presented here shows how we can create the data that the PWM generation code needs to run. The timer driven PWM code presented here works in terms of two byte pulse durations and a 1 byte value that determines which pulses are still being generated.

As I mentioned recently, the original servo controller firmware that I posted was flawed and wasn’t suitable to use as a base for the more complex servo control code that I want to add to the controller. The new firmware follows the design that I spoke of here and relies on the ATTiny’s 16-bit timer to generate our PWM signals. Since we’re using a timer we don’t need to waste processor time with hard-coded timing loops full of ’nop’s as we did in the original firmware and this gives us much more time to do useful work.

As I mentioned here, there’s a fundamental design problem with the two versions of the ATTiny2313 servo controller firmware that I’ve presented so far (see the 8 channel source code and the 64 channel source code). The timing that determines the shape of the PWM signals that are generated relies on carefully crafted timing loops and the time taken by particular code sequences and this is affected by the interrupt driven serial I/O that is used to control the controller.