THE MAGAZINE FOR COMPUTER APPLICATIONS
Circuit Cellar Online offers articles illustrating creative solutions
and unique applications through complete projects, practical
tutorials, and useful design techniques.

UPGRADING USING DATA PACKETS

by George Martin

Start ý So Far, So Good ý Be Careful What You Design For ý You Just Might Get It ý Sources and PDF

This month, I find myself caught between two hard and fast systems requirements. The first requirement is that the system operate as fast as possible. The second requirement is that upgrading the hardware and software in the field be as smooth as possible. Sounds familiar, doesnýt it?

Let me try to explain the particulars a bit more. My specific system is a communications system, but the issues I discuss in this article can easily apply to almost any embedded system. "As fast as possible" is measured in the response time to user inputs. Imagine a push-to-talk button that keys a transmitter. Any delay in responding to this input will be noticeable. Another example is going off hook and getting a dial tone. Again, any delay here and you will notice.

The upgrade requirements stipulate that the system operate during an upgrade. Yes, you read that correctly. This means that new hardware will be present in systems with old software and vice versa. Also, as new hardware and software become available, new data will flow through the system. Old software needs to not get confused by this new data. And, old and new software need to recognize and communicate with each other.

To get an idea of what this system will look like, imagine several separate complete systems connected by a high-speed network. My problems arise with the data packets that keep these separate systems talking to each other. My hardware uses custom HDLC controllers to ship the data back and forth, but yours might use standard 10BaseT hardware. These data channels are always running, sending fixed size packets full of data when data is available and sending null packets when nothing is available. The transmit/receive buffer size can be configured in the HDLC controller. I selected a large buffer size to place enough data to process in one pass, one that would hold my largest packet (or so I thought). And if my data got larger, I could just split it between two packets. I realize this would require more processing time at the receiving end to piece the data back together.

Also, I need to be able to share data and commands with all the units connected to the network, and these units will be running different versions of the software. My first approach was to define a structure for the packets that went something like what you see in Listing 1.

The PacketType variable could be used to identify different data and status packets. I even went so far as to match the layout of the data in the packets with the data layout in my memory. This way, I could use memcpy to move the data in and out of the HDLC buffers for transmitting and receiving.

NEXT