Date: Tue, 25 Oct 2005 00:35:18 -0500 (CDT)
Subject: bit banging serial output
X-UID: 96
Content-Type: IMAGE/JPEG; name="img2389.jpg"

The vacation was great. It was so good that it's taken me about a week to 
get back to work building the robot.

One plan is to use GPIO pins (general purpose I/O) on one of the Geode 
computer boards for 5 volt TTL serial with the microcontroller. As the 
microcontroller will run at 1 MHz, which is not an even multiple of the 
serial baud rate, there will be a level of error in the communications.

The microcontroller reads in octets from the UART and flashes the LEDs 
with the values.

// clock speed is 1 MHz
#define F_CPU 1E6

#include <avr/io.h>
#include <avr/delay.h>

int main()
{
   UBRR  = 0x19;            // 2400 baud at 1 MHz clock
   UCR   = _BV(RXEN);       // enable receiver
   WDTCR = 0x00;            // disable watchdog
   ACSR  = 0x80;            // disable analog comparator

   DDRB  = 0xff;            // output on STK 500 LED pins
                            // note LED is on when pin is low and off when high

   while (1) // forever
   {
     PORTB = UDR;           // set LEDs to serial receive byte
     _delay_ms(1);          // delay to prevent busy loop, is longer than 1 ms
   }
}

With the oscilloscope, it is pretty easy to "dial in" a shell script that 
sends the byte 0x59 to the microcontroller. The file low.txt consists of 
24 '0' characters followed by a LF. The file high.txt consists of 24 '1' 
characters followed by a LF.

#!/bin/sh

while [ 1 ]
do
   cat low.txt \
       high.txt low.txt low.txt high.txt \
       low.txt low.txt high.txt low.txt \
       high.txt \
       > /dev/gpio0
done

The problem is that there is a lot of jitter. The microcontroller is 
receiving at 2400 baud which implies a pulse width of 416 us. Watching the 
scope, the pulses vary from about 320 us to 470 us. The scope is 
invaluable. It would be impossible to have this kind of visibility without 
it.

To make this work, the serial protocol needs to be designed to detect 
errors. It doesn't need to be fast. But the robot shouldn't suddenly go 
crazy and go to full speed (probably around 20 mph) and crash into 
something.

Next thing to try is SPI and I2C. These are externally clocked serial 
interfaces. So the jitter issue should go away. Communications will be 
really slow when done with bit banging in software. For this application, 
slow and reliable is ok. Using non-UART serial comms makes me nervous as 
motor control is critical to safety.

I'm not rushing this so I don't have to go back and re-do work. That's the 
pattern I've fallen into with this project. You don't save time. In the 
end, it takes about the same amount of time as if the job had been done 
right the first time. The only way to save time is when you have a lot of 
experience and know exactly what you are doing.

It's becoming cold so I may have to complete and paint the frame this 
weekend. If it becomes too cold, painting will be difficult. I have blue 
and white Rust-Oleum enamel. At first, the blue seemed kind of lame to me. 
But then I saw episodes of Ghost in the Shell: Stand Alone Complex. The 
Tachikoma robots are painted blue and white. My robot won't be nearly as 
cool as a Tachikoma (too primitive and simple) but the symbolism is still 
there for me.