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
   30   31   32   33   34   35   36   37   38   39   40