is a single bunch of data that is sent out in a
transaction from the master to the slave.
Figure 1. Data setup and clock timing.
The solution? Combine the ideas. We’ll take the
address and command fields along with the two I/O line
hardware interface from I2C and combine it with the simple
SPI interface that doesn’t have to do bus arbitration
(decides which master can talk). If we include an address
and command field with the data that we clock out, then
we can have addressable devices without needing an
additional select line. Since I can’t resist creating my own
bus design, this sounds perfect!
If you want more information on these two common
synchronous serial bus implementations, you can always
Google them on the Internet. There is a lot of information
out there that can help you understand these ideas.
THE DESIGN: A two-wire bus
with simple address/command/
data packets.
Here is the packet format that I’ve settled on. A packet
Figure 2. Sensor board schematic.
[ 8 bit address] [ 8 bit
command] [ 16 bits of data]
Some commands will be sending data out to
the device to do things like set a motor controller
speed or set up some sensor condition. Some
commands will want to get data back from a
sensor. This latter operation means that I’ll have to
flip the direction of flow on the data I/O line after
the address and command bytes are sent. This is
easy to do as you’ll see later on with the code examples.
Basically, the master and slave need to know when the
data line flip should occur. I decided that the write back
commands will have the MSB (Most Significant Bit) of the
byte set (means equal to 1) when the command requires
data to come back from the slave to the master.
Additionally, I need to decide how the data will be read
at both the master and slave sides. My choices were that
the slave will read a data bit on the rising edge of the
clock, so that data has be ready and stable at the master
when the master transitions the clock from low to high.
When the slave sends data back to the master, it will set up
the data on the rising edge of the clock; the master will
then read the data line on the falling edge of the clock.
Take a look at Figure 1 to help you understand what I’m
talking about. When you are designing a communications
protocol and hardware system, there are a lot of details you
need to work out carefully if you want it to work properly!
Figure 1 shows the bit timing for the clock and data.
You can see that the master has to have the data set up
and ready before it transitions
the clock from low to high. The
slave, on the other hand, only
needs to set the data up when
the clock transitions from low
to high since we specify that
the master reads the data when
the clock transitions from high
to low. We have lots of time for
the data line to settle before
the master reads it.
THE HARDWARE:
The sensor slave
hardware board.
Now that we’ve got the
protocol all settled, what
hardware will it run on? In my
case (as with most hobbyists),
that decision was made by
looking in the junk drawer to
see what I had a bunch of at
14 SERVO 06.2009
