Page 144 - Embedded Microprocessor Systems Real World Design

ing mode. This characteristic would not be immediately obvious looking at
pseudocode.
Saying that, the primary advantage to pseudocode also is that it isn’t graphical,
so you can write it with the same text editor you write code with. In addition, you
can embed the pseudocode-at whatever level it is written-into the final source
code as comments. This may be important down the road if the graphical charts
will be lost somewhere along the way but the source code won’t.
There is no reason you can’t use a combination of techniques to document your
code. You could use a high-level state diagram, like the ones shown for the pool
timer code, to provide a clear graphical representation of software states. At some
lower level, you can switch to pseudocode that eventually becomes part of the
source code comments.
In a complex system, it is a good idea to have multiple levels of documentation.
An overall block diagram shows what data are transferred in and out of the system,
another diagram shows what is passed between subsystems or boards or the major
firmware functions, and pseudocode or state diagrams describe how each of the
functions works.

Partitioning the Code

The charts and diagrams shown so far assume that you already know how the code
will be functionally partitioned. The process for determining this breakdown and
developing the code is the same as for any software, but with a few additional con-
siderations for embedded systems:

In a PC, an operating system controls access to the disk drive, display, and other
peripherals. While there are real-time operating systems, which we’ll cover in
Chapter 9, most simple embedded designs have none. In these cases, some mech-
anism must arbitrate access to peripherals and memory. Two serial transmit
routines cannot both be filling the same buffer, for example. The simplest way
to do this is to have each resource (serial I/O, interface buffers, and so on) con-
trolled by only one piece of code. This seems obvious, but it is easy to cheat when
sending a byte over the serial interface is as simple as an assembly language move
instruction. In cases where this rule cannot be followed, usually because of
throughput, make sure that conflicts do not occur.
Since the code is stored in programmable read-only memory (PROM), self-
modlfylng code is out. This is considered bad practice anyway, but it is nearly
impossible in an embedded system. Self-adapting code, however, is possible if
nonvolatile storage is available.
Some software engineers write code for maximum maintainability, some for
maximum efficiency, and some for minimum space. Some embedded systems can

Software Design 125