Microcontroller Design Checklist

Or,

My Top Seven uController Issues

This is my checklist that I use when approaching a new embedded system project using a uController. Its not complete and I add to it whenever I think of new things. There are 3 major goals for this checklist:

• Sizing the uController, e.g. which chip to use?
• Identify all the development tasks.
• Uncover any "gotchas" and identify the critical paths, e.g. what's risky and what's hard?

I group things into 7 key issues:

1.0 The "Data Path"

2.0 The "Control Path"

3.0 Memory

4.0 Real-Time

5.0 Persistence

6.0 Tools/Development

7.0 Chips and Board

All hardware and software projects should include a requirements analysis, user interface evaluation, documentation, etc. etc. This is not intended to replace all that - just highlight some of the special microcontroller issues we face.

1.0 The "Data Path"

Borrowed from hardware design lingo; the "Data Path" refers to how the microcontroller does its math and data handling. A small PIC 16C54 microcontroller, for example, has an 8-bit data path and is capable of directly doing 8-bit ADDs and SUBs but not Multiplies or Divides. Larger widths can always be accomplished in software, but at the expense of memory and speed.

• List as many data variables as possible. This is also known as a "data dictionary".
• For each variable, list its required range (1 bit, 8-bits, 10-bits or 64-bits).
• List the number of uController "words" required. If your compiler/assembler is able to easily manipulte single bit booleans with Bit Manipulation instructions, then you may allocate multiple bit variable into words.
• If the current processor candidate has a smaller data path than the variable, then you must do multi-word processing (e.g. doing 16-bit adds on an 8-bit processor). Compile some examples of all multi-word operations to see how many code and data words are required.
• List all operations required. Do you need Multiplication? List this. Do you need Table Lookup? List this. Also include the precision required.
• Consider math "tricks". You may not need to do full division, if you can get away with some clever SHIFTing. You may be able to avoid expensive multi-word processing if you can instead utilize some Look-up Tables (e.g. memory vs. MIPS).

List any major "functions" or computations. This is NOT a list of all the functions of the program, but rather specific data functions such as a FIR filter, or 'Interpolate PWM Table Values'. Many applications may not need this sort of list (e.g. the Elevator or Traffic Light Controller really does not do any elaborate math functions beyond just adding and subtracting).

2.0 The "Control Path"

Again, borrowed from hardware design lingo; the "Control Path" is the firmware portion that creates the sequence of actions and provides the decision making. State Machines, Rules, etc. make up the control path. Try to establish a sense of how many states, modes, rules, etc. the program needs. Compile some code examples and count the memory and cycles required to do, say, a state machine with 6 states using an 8-bit state variable. You may be surprised! List control variables in the same manner that data variables were cataloged.

List all your major program functions. This is just the outlining of software and not unique to microcontrollers, so I won't say any more.

3.0 Memory

The analysis done above in sections 1.0 and 2.0 naturally provides an estimate of memory requirements. You should be keeping a column of "words required" for all variables. The total memory required is, of course, always an art of estimation. Judge the risk of choosing too small a memory footprint against the need for room to grow and cost of unused memory. Optimally, pick a microcontroller family with a range of memory sizes within identical packages.

4.0 Real-Time

Firmware projects usually have real-time requirements. Some requirements are more stringent than others. Performing the debounce delay for a keypad switch is a much easier real-time contraint than is measuring the frequency of an audio input signal. Some real-time requirements will require simple software tricks while others will require dedicated hardware solutions. Do not confuse this list of real-time "tasks" with general firmware tasks. The key words here are real-time. Also note that I am not refering to a RTOS "task" (BTW: my personal experience has been that I implement my designs in a very state-based manner and have rarely felt the need for a RTOS).

• List each real-time requirement or "task". Some example tasks include; keyboard debounce, flashing LCD cursor, PWM output, sense status pulse from external connector
• For each real-time task, fill in several columns as shown in the example below.

Task	Description	Latency	Period	Implementation
Keyboard Debounce	Detect a switch closure and ignore switch for some debounce period after sensing initial closure. Switches will be fairly clunky mechanical toggle switches.	Soft latency requirement. Detect initial edge no later than 50 ms. Debounce interval is about 250 ms +/- 50 ms	500 ms	Software down-counters based on some real-time clock (TIMER0).
PWM Motor output	Control DC motor speed using PWM. Motor spec sheet specifies typcial PWM parameters.	Soft Latency requirement.	80 ms PWM period. 8-bit PWM resolution.	Use TIMER1 with PWM setting.
User "beeps"	Beep when keypad depressed. Existing Beeper requires square-wave to drive.	Soft latency, but keep below 100 ms to maintain imperceptible delay.	Use a 2000 Hz tone, therefore period is 0.5 ms +/- 5%. Beep duraction is about 100 ms +/- 25%.	Generate square wave by direct program delay loops. THIS IS PRE-EMPTIVE but no other firmware-based hard latency requirement is present. Note that beeping is only required during setup and not during operation when the optical switches are polled.
Detect optical "switch"closures from assembly line sensors.	Detect the ENTER and EXIT pulses for the metal ingots.	Must respond to pulses within 1 ms.	Min pulse width is 4 ms, Max pulse width is 1 second. Min period is 25 ms.	Firmware polling.

• Note whenever a firmware task is pre-emptive. If one real-time task's implemention preempts some other set of real-time tasks, then you must ensure that NOT doing those pre-empted tasks doesn't break the system (got that?). Always assume the worst case and not rely on probabilities!
• Maintain the 'Implementation' column stating what hardware resources are required. This table may inform you that you need 3 hardware timers instead of the 2 you originally thought you needed.
• Keep in mind your desired crystal speed. This detirmines the resolution of your timers, detirmines achievable latencies, and available MIPS.
• Will unit ever be "asleep"? If so, will it need to respond to any real-time event with some latency? Check data sheet for constraints.
• Always strive for a very "state-based" firmware approach where the processor never gets bogged down deep into any one function. Do things in a main-loop where each sub-function is done based on precise states. Use interrupts only when it makes sense; required by real-time constraints. Be event-driven. Think 'State Machines'. Remember - a big, time consuming FOR loop that takes 100ms to complete means you won't do anything else (except maybe an interrupt) while you are in that loop.

5.0 Persistence

Undetected persistence requirements can be a real show-stopper and wreck a project if discovered too late. Persistent variables (or "non-volatile" variables) keep their values even if the box is turned off and on again. For example, your unit may have a network address, some operating parameters, event counters, etc.

• List all variables that must be persistent. You can add some columns to your Data Path or Control Path variables if you wish, or keep them seperate (my preference)
• List the width of each variable (e.g. 1-bit, 8-bit, 64-bits)
• List the update rate of the variable. A unit address may never change during the life of the device, whereas an event counter may change every millisecond.
• List the number of times each variable will ever be changed over the lifetime of the box.
• Note any persistent variables that are updated at the factory versus in the field (this raises the issue of "provisioning").

The list above will detirmine how much persistence storage is required (e.g. 4 bytes or 4 Kbytes). The number of times any variable changes may detirmine the hardware implementation, for example, most EEPROM memories only allow about 100,000 writes. If you must maintain a persistent variable that changes very, very fast or frequently and is therefore inappropriate for EEPROM or FLASH, then you may have to consider alternatives like battery-backed SRAM, Power Fail Detect or EEPROM with "shadow ram". Some microcontrollers conveniently include some EEPROM. If not, some traditional semiconductor companies offering non-volative memory include; XICOR (EEPROM, EEPROM with "shadow SRAM"), Dallas Semiconductor (Battery-backed SRAM), AMD (FLASH) and ATMEL (FLASH and EEPROM).

The bottom line is to consider persistence very, very carefully.

6.0 Tools/Development

Here are some key points and ideas:

• Can a C compiler be used? Try some test compiles if there is concern.
• Use a simulator if available for certain bugs or tests.
• Emulator? Will emulator work with desired package, voltage, etc. Check to make sure!
• Consider initial development in C on a PC with "fake" functions for I/O etc. This can save great amounts of time. Prove out math algorithms on PC.
• Consider using unused pins for test inputs and outputs.
• Consider using an available uController UART for a console port or just for outputing debug messages. Time spent wiring up a RS232 driver and hooking up to PC is often well worth it especially if emulator unavailable.
• Consider PCB test point for easy Logic analyser connection. Optionally populate a header that Logic Analyzer directly connects to!
• Use Visual Basic program on PC to communicate over a serial port on embedded system. Looks great, and great for testing and even manufacturing needs (even for end user!)
• Use MAKE, perhaps use Source Code Control (e.g. RCS).
• Include in source code header; Version, Revisions History, Minimum "MAKE" information, Processor resources used (what percentage memory used up?) and versions of Compiler/Assembler used.

7.0 Chips and Board

Again, here are some miscellanious checklist items.

• Package - will DIP be easier for test? Fine-pitch packages may be problematic.
• Operating voltage (consider interfaces, including emulator)
• How to reset?
• Power up or down sequence constraints?
• Temperature range; Industrial vs. Commercial.
• Manufacturing programming; OTP? ROM? ISP?
• Can a simple PCB feature permit In-Circuit Programming?
• How will firmware version be associated with any particular board? Labels? Can it be queried?
• Will any Opto-Isolation be required? Check! Severe cost implications if yes.

Back to Tom Coonan's Main Page