Date: Fri, 28 Oct 2005 01:47:51 -0500 (CDT)
Subject: serial protocol between computer and microcontroller
X-UID: 98

This protocol is somewhat resistant to framing and synchronization errors 
by design. It's based on three octet datagrams. This makes it very simple. 
There's probably some information theory that describes an optimal family 
of protocols in the presence of different kinds of errors. I just used 
intuition.

The functionality isn't implemented yet. I've only tested sending frames 
from the computer to the microcontroller. Tomorrow I'll test the other 
direction. Once I know that the communications protocol is solid, I'll 
write the motor control and sensor code.

Also, I'm not going to paint the robot frame this weekend. After some 
thought, that is the lowest priority. Highest priority is getting this 
software working so that the electronics can be reassembled and everything 
electrical works.

// One bit left or right shifts due to jitter and timing errors corrupt byte
// 1, the command. Byte 2 specifiers are also corrupted. Byte 2 values are
// not corrupted. Any shifts are not detected for byte 2 values.
//
// If a CRC checksum were introduced, this may not be any better than the
// unreliable datagram protocol below. An ignored command due to CRC
// checksum error detection can also be bad. Unless there is a request and
// confirmed response, the sender can not know if the command is followed.
//
// e.g. If a command to stop the drive motors is ignored, this could result
//      in a crash.
//
// The easy way to address this is for the sender to continuously send
// commands at high frequency relative to the system under control (several
// hundred times per second). Any dropped commands do not matter and are
// averaged out.
//
// *** Serial protocol to microcontroller ***
//
// byte 0 - framing byte
// 0xff             - value only occurs as framing byte
//
// byte 1 - command
// 0x03             - set duty cycle for OC0   (middle A)
// 0x0f             - set duty cycle for OC1a  (left   B)
// 0xf0             - set duty cycle for OC1b  (left   A)
// 0x30             - set duty cycle for OC2   (middle B)
// 0x0e             - set PC4 on               (right  A)
// 0xe0             - set PC5 on               (right  B)
// 0x01             - send pulse to gyro
// 0x10             - read voltage
//
// byte 2 - value or specifier
// 0x00 to 0xfe     - duty cycle
//                  - number of pulses for PC4/5
//                  - delay count for pulse width to gyro
// 0x06             - sharp IR sensor 0      (read voltage)
// 0x60             - sharp IR sensor 1      (read voltage)
// 0xc3             - steering potentiometer (read voltage)
//
// *** Serial protocol from microcontroller ***
//
// byte 0 - framing byte
// 0x00             - value only occurs as framing byte
//
// byte 1 - request command
// 0x06             - send pulse to gyro
// 0x61             - read voltage of sharp IR sensor 0
// 0x63             - read voltage of sharp IR sensor 1
// 0x67             - read voltage of steering potentiometer
//
// byte 2 - value
// 0x01 to 0xfe     - delay count for pulse width from gyro
//                  - left adjusted ADCH from A/D voltage conversion
//
// Note that 0xff is an illegal value for data from the micrcontroller.
// The reason is that 8-N-1 implies the line is normally held high. It
// only pulls low for the start bit, followed by the transmitted bits.
// Excluding 0xff simplifies frame detection when using bit banging on
// the computer side.