\documentstyle[11pt]{article}
\begin{document}
\title{Parallel To Serial Robot Controller}
\author{Slamet Hendry and Andrew Heininger}
\maketitle

\section{Introduction}

After building a stiquito robot we need an interface to control it.
The simplest method is to build a parallel interface but this
involves the usage of at least 8 control wires between the robot
and the interface. This may be undesirable because we would like to make
our robot autonomous. An alternative is to build a serial controller 
which only needs only two or three control wires. We offer such a design
(see figure 1) which we built on an Actel Programmable
part. By using such a chip, the builder can add their own custom
devices which use the serial interface for their I/O. This allows all
of the digital circuits to be on one chip and this gives us a better
weight to parts ratio (which is important because Stiquito can only
carry a limited amount of weight!).

\section{PC-Interface Protocol}

We wanted our design to be flexible enough to handle both a
small and large number of inputs and outputs easily. We should be able
to build a six legged robot or a twenty legged centipede and not have
to change the interface design. We also wanted the interface to have
the capability to manipulate more than one thing at a time. For
example, we may want to turn on all five legs at exactly the same
time. The protocol we came up with
works as follows: (see figure 2) the user must first specify a
device's address which
they wish to read or write to. The address is made up of eight bits,
with the leftmost significant one being the the read/write bit. If set
to one, it
tells the interface that the PC wants to read the given address and
eight bits of data are sent back to it. When this bit is not set,
this tells the interface that the PC wants to send eight bits of data
to the specified address and it waits until this event occurs.
The interface can therefore have $2^7$ 8 bit devices for
both input and for output. We lay most of the responsibility on the PC
to follow these handshake conventions, so the interface doesn't need
to perform any error checking. We are also assuming that no
transmission errors will occur while sending or receiving over the
serial lines. We feel that for most uses this will not affect the
performance of the robot, but if the builder wishes, they can use a
data bit for parity checking within a given device.

\section{Serial Concepts}

We will be using the RS232 serial standards for our project, which
generally uses three wires, one for sending, one for receiving and one
for a ground (there are other lines which we won't be concerned with).
Looking at the PC (with Pin 1 being the right-most pin),
the serial connector pins have the following signals:
\begin{itemize}
	\item Pin 1 Shield ground, used for grounding the cable shield.
	\item Pin 2 Transmit Data
	\item Pin 3 Receive Data
	\item Pin 4 Request to send Data
	\item Pin 7 Ground
\end{itemize}
These pin assignments are taken from a standard computer manual, but
you might want to check your machine's specifications. 

	The serial transmit and receive lines operate between -12 and
+12 volts, while our ACTEL chips operate at 0 to 5 volts. This means
that we will also need to provide a way to drop this voltage down to
the correct level before it reaches the ACTEL part. We can do this at
the PC end by using a Motorola MC1489 (12volts $\rightarrow $ 5volts) and a Motorola
MC1488 (5volts $ \rightarrow $ 12volts) to do the job.
Attaching this circuit at the PC end would probably be the best
idea, because most PC's will be able to provide the +/-12 volts needed
for these chips. Also because the distance of the wires to Stiquito
won't be more than a few feet in length, we should have reasonable
signals to work with (remember to include a common ground wire to Stiquito!).

	A serial device sends each bit one at a time over the wire
until it is received by our interface and shifted back together into
the original size byte. The first bit sent is called the start bit and
this signals the interface that data is starting to flow in. Our
serial controller then needs the synchronize itself so that it will
sample the rest of the data bits in the center.	That way if the
signals contain any noise, we will still have a high probability of 
getting the right bit encoding.
Because we would like to be sampling in the middle, we need our interface to be
faster than the serial transfer rate. Therefore, the interface will be 8X 
that of the actual serial rate, and this should give us the precision we are
looking for. After the last bit has been decoded, the serial line returns to
its original state. For a more complete discussion of serial
communications, please see [3].

\section{State Machine}

The serial state machine ASM (see figures 3,4) has five states: 
\begin{itemize}
	\item Find Start
	\item Sync
	\item Get PC Byte
	\item Test R/W
	\item PC Read
\end{itemize}
The first state {\it Find Start} will loop until it sees the start bit from
the serial stream. When it does, it resets the counter and moves into the 
{\it Sync} state. {\it Sync}'s responsibility is to wait until we get
to the middle of the first bit from the serial stream. When we do, it
catches the value
and moves into the {\it Get PC Byte} state. This state will continue to shift
in the next seven bits. {\it Get PC byte} uses the counter
each time through its loop to keep track of the number of bits
received. After {\it Get PC Byte} has the first byte, it must
be stored in the address register. The {\it Test R/W} state then looks at the
read/write bit from the address and if this byte is set, {\it PC Read} state is
called, otherwise it returns to {\it Find Start} to receive the data byte.
If the interface needs to send a byte back to the PC, it first loads the byte
from the device (by sending the {\it OK!} signal to it) into the shifter
and then proceeding to send each bit, beginning with the start bit. The state
machine leaves each bit on the serial line for 8 clock cycles and must
return the serial line to its original default position. Because we
may need to receive two bytes from the PC (address and data), and we
use the same loop to read them in, we must keep track of which byte is
being loaded, the address byte or the data byte. This is done by
keeping an extra flip flop around and setting it when it is the first
time through the machine.

We implemented this state machine in ACTEL by using standard
techniques to first derive the equations for the behavior, reducing
them, and implementing them by
using arrays of AND's and OR's (sum of products form). This strategy
helped  to keep things clean and well organized. We also tried to use
a  hierarchical structure
to distinguish between our logic pieces and functional pieces. The user
need only look at the top cells to simulate and determine the
machine's behavior.

\section{Hardware Overview}

There are four main components to the serial interface: The State
Machine, a 7 bit counter, a 9 bit shifter and a loadable 8 bit
register (see figure 5).
The state machine controls the counter, shifter and register. The shifter is
used for both serial in and out operations. It is connected to both the
register and data bus. The register will hold the device address and the data
bus is used to convey data to the devices. The counter is used to inform the
state machine when an important operation needs to take place.

The counter is 7 bits wide to be able to handle the
9 bits when writing back to the PC and each bit will exist 
for exactly 8 clock cycles. This gives us a total of 72 clock cycles to handle
a write (similarly a read), and thus a 7 bit (128 state) counter. We use the 
shifter for both reading and writing, so it is also convenient for it to
supply the start bit when writing to the PC. It is for this purpose that
we make the shifter 9 bits wide. Finally, the register will be used for keeping
track of the current address of the device in use. It is needed because we may
need to shift in some data to write to the device and we must remember which
one.

The functionality of the counter can be described as follows:
At each clock tick the counter increases by one. If the counter should ever
reach its maximum value, the next clock tick will cause it to restart at
zero. There is also a synchronous clear signal which can be used to reset
the counter to zero. Our state machine will use the counter by resetting it
and then looking at the time to decide when an event should occur. When
the state machine isn't using the clock, it will ignore it and reset it when
it starts using it again. We have used a ripple carry counter for our
design, because it is simple and it is fast enough for our needs.

The functionality of the shifter can be described as follows:
The shifter can shift in one direction, from the lowest order bit to the
highest order bit. It can load input from 9 bits, and it can hold its
current output. When shifting, the input to the lowest order bit will come from the
serial wire. We have built our shifter from 4 bit multiplexers connected to
D flip flops. We have then made the appropriate connections between bit slices.
We have two select wires which correspond to loading, shifting and holding. Because
the state machine only expects to be shifting and loading, it may be necessary
to throw in a black box which generates this conversion in the logic.

The functionality of the 8 bit loadable register can be described as follows:
When given the address load signal, it will load its registers and hold the
values until the next load command is given. This was built using
two input multiplexers (one input for the next value and one for holding
the current value) and D flip flops.

There are also two black box circuits added. One for the shifter to
convert the signals {\it shift} and {\it load shifter} from the state
machine into {\it select0} and {\it select1} which the shifter can
understand. Also there is a small circuit needed to assure that the
{\it line-out} will always default to a high signal when the interface
is not transmitting to the PC. These two circuits could easily be
combined into the state machine, but they remain as a patch in our project!

\section{Devices}
	The devices will actually handle the responsibility of
controlling sensors and legs on the robot. An input sensor can have an
array of power buffers leading to a bank of D enabled flip flops
connected to the {\it Data Out Bus} (see figure 6). Each device will
have its own address decoder so that it will be able to recognize when
to respond to the interface events. An output device will also have an
array of D loadable flip flops leading to a bank of power buffers
attached to the legs. The input to the output device will be from the
{\it Data In Bus} and will occur when the user selects it from the PC.

These devices can add flexibility and power when we use them in more
creative ways. For example, we may decide to build a loadable counter
which sends a pulse out to a Stiquito leg each time it reaches zero.
We may decide to encode a number of sensors so that our device will
always provide us with the one that is the most important. A device
might perform some calculation for the robot. Device designs are only
limited by your imagination and the size of the ACTEL part you use! 


\section{Scope of Research}

We have implemented the serial to parallel interface in ACTEL and
simulated it in software. There still remain a couple of steps
which must be undertaken before this work can make a Stiquito robot walk.
The ACTEL part operates at 0 to 5 volts while the parallel port on the
PC operates between -12 to +12 volts. The builder will need to add the
Motorola conversion chips (MC1488 and MC1489) before hooking up the
chip. Also since our design only handles the general protocol of the
interface, it is necessary to design some devices to pack onto the
chip with it. We have tried to briefly outline how such devices can be
built, but these should also be tested with our design before
programming a final chip. The Stiquito legs require more current than an
ACTEL part can provide so the builder will need to add one power
transistor per leg. One such part is the {\it Archer} TIP31 NPN
transistor available from Radio Shack. If the ACTEL part will be
powered from a battery, the builder might also want to include a
circuit to regulate the power. Finally, software must be written to
control the interface and provide the logic for a walking gait.


% There are two main enhancements from this project. First, because of
% the protocol we can simplify the number of wires in the interface to two,
% a ground and a transmit/receive wire. This requires further circuitry back
% at the PC so that the PC won't get confused. 
% Secondly, we might be able to have a wireless serial interface by adding
% infrared circuits at both the PC and interface ends. There are many
% chips which implement the power we need and it shouldn't be hard to
% find such a candidate. We are already doing the hard stuff to
% serialize the signals, for wireless transmission, we simply hand off
% these signals to the transmitter and receiver.
 
\section{Files}

The ACTEL files are structured according to figure 7. The topmost file is 
called ``hhtop'', and contains the full design of the interface. One level
down there are files ``hhs2p'', ``hhshiftr'', ``hhreg''.

\begin{itemize}
 \item hhtop: contains the top level schematic for the full
  interface design; it also includes the files below.
 \item hhs2p: contains the schematic for the ASM's state machine,
  output signals, and the input signals.
 \item hhshiftr: contains the schematic for the universal 9-bit shifter.
 \item hhreg: contains the schematic for the 8-bit address register.
\end{itemize}

The command file for the ACTEL simulation is called "hhtop.cmd". It 
contains both the simulation commands and the input data. 
\newpage

\begin{flushleft} {\Large References:} \end{flushleft}

1] 1992, Jonathan W. Mills, {\it Stiquito: A Small, Simple,
Inexpensive Hexapod Robot }, Indiana University Technical Report No.
363a, Indiana University Computer Science Department, Bloomington, IN.

2] 1989, Steve Leibson, {\it The Handbook Of Microcomputing
Interfacing }, second edition, TAB Books, Blue Ridge Summit, PA.

3] 1987, F. Prosser, D. Winkel, {\it The Art of Digital Design }, second
edition, Prentice-Hall Englewood Cliffs, NJ.

\end{document}
