Page 35 - Embedded Microprocessor Systems Real World Design
P. 35
On a large project, these costs usually are minimal. On a small project, they can
drive development costs above what the product will produce in sales.
Hardware and Software Requirements
If the product specifications or requirements definition is the goal for the product,
the hardware and software requirements are the goal for the detailed design. These
requirements start with definition of the user interface and system functionality. In
the example system, the complete system definition (see Appendix A) specifies what
must be done and how the user operates the device.
From the system definition, a hardware interface is defined. The most produc-
tive method of defining the hardware is to start with the requirements-what the
hardware must have. This is tied to the system specifications because the hardware
must support whatever functionality the system has. In the example system, the time
must be displayed. Given the constraints of the system (the timer will not be con-
nected to a PC, for example, so a CRT display is out), it came down to two choices:
light-emitting diode (LED) and liquid crystal display (LCD). Even though an LCD
would be more readable, I chose the LED display because the timer will be exposed
to the weather all year, and the LCD displays available at the time had problems
with cold temperature.
Some people consider each set of specifications to be a fixed, immutable docu-
ment. I prefer that the hardware specifications be a record of the design decisions.
The first section of the hardware specifications is the requirements. This is given
to the hardware engineer and becomes the basis for what he or she does. The
requirements should spell out just that-the requirements. How the requirements
are met is up to the engineer. Anything that cannot be left to the engineer’s
discretion should be in the requirements document. Of course, what you leave to
the engineer’s discretion may be different for a new college graduate than for an
engineer with 10 years of experience.
When working as a project engineer on a large project, I like to put a list of the
requirements for each microprocessor-based board in the engineering specifica-
tions. This single document then becomes the foundation for the individual board
specifications.
After the requirements document is completed and while the design is pro-
gressing, the hardware specifications are updated to include the specific informa-
tion that another engineer needs to understand the design and that the software
engineer needs to program around the hardware. So, when the board specifica-
tions are completed, a preface is added that describes the original requirements
(and any updates that occurred as the design progressed) and a description of how
20 Embedded Microprocessor Systems