COMPUTER
COMMUNICATIONS
I
needed a way of getting data from the computer
to the AT45DB041B DataFlash, so I used a specialized
protocol. The main feature is that it’s optimized
for the DataFlash because each data packet is
264 bytes. This made loading the AT45DB041B
easy because I could send data quickly to fill
up one page buffer, write the page, and start
sending data for the next buffer. At 115,200
bps, my FPGA configuration file takes about
15 to 20 s to send over the serial port.
Having
the ability to use all of the ATmega88’s bootloader
space is important. It’s easy to create a communications
protocol using CRC-8 and other such features
for reliable data transmission. Normally, the
added overhead in code size wouldn’t be worth
it, but there’s no real penalty here. The following
LUB packet isn’t anything too special. It shows
just the normal verification features such as
packet numbers and CRC:
[SYNC]
[Packet Number] [Packet Type]
[Data LSB] ... [Data MSB] [CRC8]
The
synchronization byte is used as a simple start
of packet. The packet number starts at 1 for
the first packet and is 1 byte long. It rolls
over to 0 for more than 255 packets. The packet
type defines how many data bytes should be expected.
It also issues commands. After every packet,
an ACK or NACK returns and tells the sender
if it needs to resend something.
This
process of ACKing every packet is useful for
controlling the data rate. The sender will send
the next packet of 264 bytes only after it receives
an ACK for the previous packet. This means the
receiver can wait until the 264 bytes have been
processed and stored before requesting the next
packet by ACKing the previous packet (see Figure
2).
|
(Click
here to enlarge)
|
Figure
2—Typical LUB communication is simple. The
right arrows signify communication from
the computer. The left arrows signify communication
from the LUB. |
There
is a common code base for both the PC end and
the AVR end. There is a slight trade-off in
speed, but the code is much easier to maintain
this way.
