May 2009 Archives

The jitters and general instability of the hacked together simple servo controller (see here) for the ATtiny2313 were, it seems, down to the fact that the internal clock wasn't stable enough and this caused enough timing issues to throw the PWM off enough to jiggle the servo position around rather than hold it steady. This morning my external 4MHz crystals arrived and after changing the processor's fuse bits to accommodate the change in clock source everything was fine and the code started behaving itself.

The source code for the servo controller follows; as mentioned before, it's a) pretty simple and b) heavily based on the code that I found here for the AT90S4414. It may be better to adjust it to work at an RS232 baud rate friendly clock speed, but I expect I'll move away from the hard coded timing loops as soon as possible if I can and this might make such clock speed adjustments slightly easier.

The next step is to expand this to use one (or more) of the demultiplexor chips so that I can expand the number of channels supported. 

CD74HCT238E

| No Comments
My progress has been slow over the past couple of weeks because a) I've been rather busy with other things and b) an order of components has gone missing in the post. The order contains some 4mhz crystals and therefore my server controller firmware testing has been on hold as I'd like to remove the potential clock instability as a potential cause of the controller jitters before continuing my debugging.

Today another parts order arrived (this what what alerted me to the loss of the first order; they were both from the same supplier and I expected them to come as a single delivery). Today's order contained some CD74HCT238E's, these are the 3 to 8 line demultiplexors that I'm intending to use to expand the PWM channels that I can produce with the ATtiny2313. The microprocessor can use three address lines to control multiple 238s and then use a single PWM channel per 238 to expand the number of channels that it can produce. First we'll send a pulse on channel1 of all the 238s, then we'll increment the common address lines and send a pulse on channel2 of all the 238s, etc. If we do this quickly enough we'll satisfy the servos 50hz refresh requirement and we'll have a servo controller that can control more servos than it has I/O pins; using 1 pin for PWM for each of the 238s and 3 pins for addressing all of them at once.

This afternoon I breadboarded up one of the 238s to the Arduino and cycled through each of the channels flashing an LED on each channel in sequence. Woo! Proof of concept...

I've also ordered some 138s which are similar but are active low rather than active high. These should also do the job of demultiplexing the signals but, I think, will require more board space and a more complicated layout as they'll need pull-up resistors. I'm not quite sure that I understand how to use the 138s as replacements for the 238s but that's part of what I'd like to understand...

Atmel ATtiny2313 Servo Controller v0.1

| No Comments
This morning I tested the first version of my custom servo controller. It's currently heavily based on the source for 16 channel servo controller that I've mentioned before. What I did was simply adjust that source for my target processor and the fact that I'm using it with a 4Mhz internal clock rather than the more standard "RS232 baud rate friendly" 3.6864 MHz that the original code used.

The main changes were to the reduce the controller from 16 channels to 8 since the ATtiny2313 doesn't have enough pins to run 16 channels and to adjust the general setup to account for the new processor. The timing loops also changed a bit due to the clock change. Since I'm working from the other code as a base my code generates the PWM signals manually in the same way that it does. Although we have custom hardware inside the ATtiny2313 that can generate PWM signals for us the manual approach seems to work at the moment. Things may well change as I get a better understanding of what I'm doing.

I initially had some problems because although I'd set the code up for a 4Mhz internal clock and simulated with that I hadn't changed the fuse bits on the processor so it was still running with the default 8Mhz internal oscillator with a divide by 8 to give a 1Mhz clock. The first hint that something was wrong with the timing was that I could see the test LED on one of the servo channels flashing rather than being solidly on; the frequency of the refresh of the pulse should be 50hz and that should look like the LED stays on rather than the flashing that I was getting at the 13hz or so that I was actually getting as a refresh. Once I calculated and set the new fuse bits (using this online calculator) the LED stabilised and plugging a servo in gave the expected results.

Since the servo controller uses the 'standard' three byte serial "SSC" protocol of 0xFF <servo> <position>, my existing control software works fine with it.

Right now the pulse frequency seems to be slightly off, which makes the servo vibrate in position a little. I'm not sure if this is down to my timing (which I expect it is) or if it's because I really should be using a more stable external clock.

Once I've tested this a little more and have something that's a little more stable I'll upload the source. What I have now is a good base for the larger capacity controller that I'll need. One of the next steps will be to reduce the number of I/O pins needed whilst increasing the number of channels supported by adding in the control of  the address lines of some 74xxx138 multiplexors which can be wired into the I/O pins that I'm using for the actual PWM output. Another thing on the list is to enhance the serial protocol, and then the controller itself, to support the various ideas I have:
  • Smooth blending between 'key frame' servo positions with the ability to stop the servo at any time before it reaches its final position.
  • Storing of multiple 'key frames' per servo so that the leg controller/gait sequencer can hand off a sequence of moves to the servo controller to blend.
  • Grouping of servos, so that we can have the blending apply across servos in the group (all 3 servos that make up a leg can arrive at their final 'key frames' at the same time).
  • etc...
Though the current servo controller design is very simplistic it seems to be a good base for these other requirements and, well, at least I now have AVR assembly code that I can build, simulate, program a device with and that actually seems to do what I expect it to do; that's a major step forward.

AVR Studio 4

| No Comments
I've been spending some time getting to know AVR Studio 4, especially the simulation and debugging functionality. It's a very functional and very useful free development suite that can be downloaded from Atmel from here.

As I mentioned a while back I have had a C compiler and development and programming tool chain set up for a while now but I hadn't got around to working out how to debug the code. AVR Studio allows me to simulate (or debug with an ICE if I had one) and is very powerful. So far I've only debugged assembly code but from the docs with WinAVR (my source of the C tool chain) imply that I can use AVR Studio to simulate and debug C code too as long as I get the debug info format correct.

The great thing about simulating the microcontroller is that I can simulate chips that I don't have (which is convenient as I have been stepping through the code for the 16 channel servo controller that I mentioned here (code available from this article, here)). At first I thought I'd need to port this code from the Atmel AT90S4414 to something that I have, but, of course, I can simply run this code in the simulator. The simulator is very powerful and shows the internal state of the microcontroller and lets you fiddle with 'virtual' input pins and watch the values of the outputs, etc. I've found that it's made it much easier to start to get a grip on AVR assembly language as I simply step through and watch the code as I would C++ on my PC. I'm currently wondering about how one goes about unit testing such code (I'm rather big into Test Driven Development and Unit Testing in my day job and would feel more comfortable writing code for my micros if I could bring some of those disciplines across with me). It seems that there's no standard solution for the AVR (at least none that the guys on AVRFreaks use) although these ideas look promising. Obviously it would be easier to test C code as there's a chance of building it on the host PC...

So far I haven't written any AVR assembly language myself yet, but I have several pages of notes and ideas as to how I can take the ideas that have been presented in the AT90S4414 servo controller code and write the servo controller that I feel I need for my robot. 

I may have been a little harsh...

| No Comments
After a little more debugging this morning I'm coming to the conclusion that I may have been a little harsh on the Arduino's software serial port.

More when I know more, but I think it's more of a flow control issue with my data transmission from the PC.

About this Archive

This page is an archive of entries from May 2009 listed from newest to oldest.

April 2009 is the previous archive.

June 2009 is the next archive.

Find recent content on the main index or look in the archives to find all content.