Page 36 - Embedded Microprocessor Systems Real World Design

the design was implemented, with all the information the software engineers need
to control the hardware. This includes the following:

Memory and 1/0 port addresses (including memory maps if appropriate)
Amount of memory available
The definition of each bit in each status register
The use of each bit on each port pin
An explanation of how peripheral devices are driven (such as the clock frequency
input to a timer IC)
Anything else the software engineer needs to know about the design

On a complex board, I have often had two separate sections in the hardware
specifications. The first section describes the hardware and how it works. The
second section contains the information the software engineers need to do their
job. In a similar fashion, a software requirements document is created that defines
what the software must do. In a simple design like the pool timer, this may consist
of the system requirements document, which describes the user interface, and the
hardware specification, which describes how the hardware works.
A detailed software specification that describes the completed design is less
common than the equivalent hardware specification. This occurs for four reasons:
1. The hardware specification is passed to the software engineers so they will know
how to manipulate the hardware. Usually, no corresponding “customer” needs
to know the technical details of the software, so the need for documentation is
not as great.
2. Software is easy to change, so it changes frequently, often whenever someone in
marketing thinks up a new feature to add. In some situations, software specifi-
cations can be very hard to keep up to date, especially if the software engineers
have other, higher priorities.
3. Software usually is the last part of a project to be finished and often not enough
time is left at the end of a project to document it. That said, company or cus-
tomer policy sometimes requires detailed software specifications. For example,
defense projects usually require extensive documentation detailing every func-
tion that the software performs.
4. The mechanical and electrical requirements are typically testable. Stresses
and tolerance stickups and power dissipations can be mathematically tested.
With software, it is more difficult to prove that the requirements are correct and
that the flowcharts really will produce code that does what was intended. The
more complex and detailed the software requirements are, the less likely it is
that you can prove the requirements to be correct. For this reason, the software
requirements document is likely to be less detailed or even to be omitted entirely
from the design process.

System Design 21