Page 143 - Embedded Microprocessor Systems Real World Design

functional description can be written, with details filled in as the design progresses,
eventually turning into pseudocode. The pseudocode and description then become
detailed comments for the actual code.
Functional descriptions and pseudocode are useful for simple systems written by
a single programmer. If multiple programmers will work on a project, and espe-
cially if multiple processors will be used, then some means should be implemented
to fully describe what information is passed between the processes and/or func-
tions done by each programmer.
Timing information for real-time functions is crucial. For example, function X
must be called within Y milliseconds of function Z or the stepper motor will lose
sync.
The following pseudocode is a description of the software I implemented in a
simple protocol converter. The system accepted serial RS232 data from a host
system, did some processing, buffered the data, and sent it to a second system via
a different interface. XON/XOFF protocol was used to control the data flow:
If serial data available, read the data,
do some proprietary stuff I cannot reveal, then
store the data in a flrst in, flrst out (FIFO) buffer.
If the buffer gets too full, and if XOFF was not sent yet,
send XOFF to the host.
If there are data in the FIFO buffer, and if the output interface
is ready, send a byte from the FIFO buffer to the output.
If the buffer gets close to empty, and if XON was not sent
yet, send XON to the host.

The software just went around and around this loop. The actual system did some
error checking and other tasks that I left out to simplify the description. Note that
the input and output processes are mostly independent of each other. The input
stores data in the FIFO buffer without knowing what the output is doing. Similarly,
the output process sends whatever is in the FIFO buffer if the output device is ready
for it. If the output is not ready, the code just waits until the next pass through the
loop and checks again. The only way one process knows what the other is doing is
by how full the FIFO buffer gets. This is a simple example that illustrates processes
that are parallel and (mostly) independent.
The more independent processes are (that is, the less data they share in
common), the more predictable each piece of code is. If processes are com-
pletely independent, some unexpected flaw in one process will not cause an un-
explained failure in another. However, there are exceptions to this, which we
will look at later.
One drawback to pseudocode is that it isn’t graphical. To use an example we
looked at earlier, the state diagram makes it obvious that there is no path from
override mode to timeset mode without going through the normal timekeep-

124 Embedded Mimojmocessm Systm