Page 142 - Embedded Microprocessor Systems Real World Design
P. 142
is the difficulty of showing all the states on a reasonable number of pages,
especially for a complex system. One way to simplify the state diagram for an
embedded system is to show the state of the outputs. This provides a consistent way
to determine what it takes to change the outputs from one state to another, as long
as the number of possible combinations isn’t too large. In the pool timer, this would
take the form of describing the state of the discrete LEDs, the information sent to
the display, and the state of the pump (ON or OFF).
Flowcharts
Another form of documentation shown in Appendix A is the flowchart for the pool
timer. To save space, only the polling loop is shown. Flowcharts seemed (to me,
anyway) to lose favor for a while, but they are coming back into popularity since
tools now simplify the process of creating and maintaining them. While flowcharts
are good at showing a single thread of execution, they don’t show preemption or
interrupts very well. Still, the flowchart is a good graphical way to show the execu-
tion of sequential code.
Flowcharts, state diagrams, and data flow diagrams all have the advantage of
being visual and relatively easy to follow. This is also one of their drawbacks-
since these diagrams are not part of the source code, they are less likely to be
updated when the code is changed. Some software manufacturers offer an inte-
grated development environment that supports graphical documentation such
as state diagrams. A typical example is Betterstate from Wind River Systems.
However, these products are typically available for development on more complex
processors. Few such tools exist for simpler processors such as 8- and 16-bit
microcontrollers.
Pseudocode
Another method of documenting the software, and one that I prefer, is to use
pseudocode. Appendix A shows two listings. The first is a high-level functional or
logical description. This listing describes in concise English exactly what the soft-
ware is going to do. I like it because it is a good way to see whether I understand
everything I need to know before coding.
The next level down is actual pseudocode, also shown in Appendix A. The
pseudocode is still a description in structured English, but additional text describes
what flags, variables, and other elements are manipulated to implement the
described functions. The advantage of this method of documentation is that the
Software Design 123