System Design

Most e m b e d d e d microprocessor designs involve processing some kind of input

to produce some kind of output, and one or both of these is usually analog. The
digital portions of an analog system, such as the microprocessor-to-memory
interface, are outside the scope of this book. However, there are some system
considerations in any design that must interface to the real world, and these will
be considered here.

Dynamic Range

Before a system can be designed, the dynamic range of the inputs and outputs
must be known. The dynamic range defines the precision that must be applied to
measuring the inputs or generating the outputs. This in turn drives other parts
of the design, such as allowable noise and the precision that is required of the
components.
A simple microprocessor-based system might read an analog input voltage and
convert it to a digital value (how this happens will be examined in Chapter 2).
Dynamic: range is usually expressed in decibels (dB) because it is usually a
m e a s u r e m e n t of relative power or voltage. However, this does not cover all the
things that a microprocessor-based system might want to measure. In simplest
terms, the dynamic range can be thought of as the largest value that must be
measured compared to (or divided by) the smallest. In most cases, the essential
n u m b e r that needs to be known is the n u m b e r of bits of precision required to
measure or control something.
As an example, say that we want to measure temperatures between 0 ~ and
100 ~ If we want to measure with 1 ~ accuracy, we would need 100 discrete
values to accomplish this. An 8-bit analog-to-digital converter (ADC) can divide an
input voltage into 256 discrete values, so this system would need only 8 bits of
precision. On the other hand, what if we want to measure the same t e m p e r a t u r e
range with 0.1 ~ accuracy? Now we need 100/.1, or 1000 discrete values, and
that means a 10-bit ADC (which can produce 1024 discrete values).

Voltage Precision
T h e n u m b e r of bits required to measure our example t e m p e r a t u r e range is
d e p e n d e n t on the range of what we are measuring (temperature, voltage, light
intensity, pressure, etc.) and not on a specific voltage range. In fact, our 0-to-
100 ~ range might be converted to a 0-to-5 volt swing or a 0-to-1 volt swing. In
either case, the dynamic range that we have to measure is the same. However, the
0-to-5 V range uses 19.5 mV steps (5v/256) for 1 ~ accuracy and 4.8 mV steps
(5v/1024) for 0.1 ~ accuracy. If we use a 0-to-1V swing, we have step sizes of
3.9 mV and 976 ~tV. This affects the ADC choices, the selection of opamps, and
other considerations. These will be examined in more detail in later chapters.
T h e important point is that the dynamic range of the system determines how
many bits of precision are needed to measure or control something; how that
range is translated into analog and then into digital values further constrains the
design.

Calibration

Dynamic range brings with it calibration issues. A certain dynamic range implies a
certain n u m b e r of bits of precision. But real parts that are used to measure real-
world things have real tolerances. A 10K resistor can be between 9900 and
10,100 ohms if it has a 1% tolerance, or between 9990 and 10,010 ohms if it has
0.1% tolerance. In addition, the resistance varies with temperature. All the other
parts in the system, including the sensors themselves, have similar variations.
These will be addressed in more detail in Chapter 9, but for now the important
thing from a system point of view is this: how will the required accuracy be
achieved?
For example, say we're still trying to measure that 0-to- 100 ~ temperature range.
Measurement with 1 ~ accuracy may be achievable without adjustments. However,
you might find that the 0.1 ~ figure requires some kind of calibration because you
can't get a temperature sensor in your price range with that accuracy. You may have
to include an adjustment in the design to compensate for this variation.
T h e need for a calibration step implies other things. Will the part of the system
with the t e m p e r a t u r e sensor be part of the board that contains the compensation?
If not, how do you keep the two parts together once calibration is performed?
And what if the field engineer has to change the sensor in the field? Will the

2 Analog Interfacing to Embedded Microprocessor Systems

e n g i n e e r be able to do the calibration? Will it really be cheaper, in production,
to a d d a calibration step to the assembly p r o c e d u r e than to p u r c h a s e a m o r e
accurate sensor?
In m a n y cases in which an a d j u s t m e n t is n e e d e d , the resulting calibration
p a r a m e t e r s can be calculated in software and stored. For example, you might
bring the system (or just the sensor) to a known t e m p e r a t u r e a n d m e a s u r e the
output. You know that an ideal sensor should p r o d u c e an o u t p u t voltage X for
t e m p e r a t u r e T, but the real sensor produces an o u t p u t voltage Y for t e m p e r a t u r e
T. By m e a s u r i n g the o u t p u t at several t e m p e r a t u r e s , you can build up a table of
information that relates the o u t p u t of that specific sensor to t e m p e r a t u r e . This
information can be stored in the microprocessor's m e m o r y . W h e n the micropro-
cessor reads the sensor, it looks in the m e m o r y (or does a calculation) to deter-
mine the actual t e m p e r a t u r e .
You would want to look at storing this calibration with the sensor if it was not
physically located with the microprocessor. T h a t way, the sensor could be chan-
ged without recalibrating. Figure 1.1 shows three means of h a n d l i n g this calibra-
tion. In d i a g r a m A, a microprocessor connects to a r e m o t e sensor via a cable. T h e
microprocessor stores the calibration information in its E E P R O M or flash m e m -
ory. T h e tradeoffs for this m e t h o d are:

9 Once the system is calibrated, the sensor has to stay with that microprocessor
board. If either the sensor or the microprocessor is c h a n g e d , the system has to
be recalibrated.
9 If the sensor or microprocessor is c h a n g e d and recalibration is not p e r f o r m e d ,
the results will be incorrect, but there is no way to know that the results are
incorrect unless the microprocessor has a m e a n s to identify specific sensors.
9 Data for all the sensors can be stored in one place, r e q u i r i n g less m e m o r y than
o t h e r methods. In addition, if the calibration is p e r f o r m e d by calculation
instead of by table lookup, all sensors that are the same can use the same
software routines, each sensor just having different calibration constants.

Diagram B in Figure 1.1 shows an alternative m e t h o d of handling a r e m o t e

sensor, in which the EEPROM that contains the calibration data is located on the
board with the sensor. This EEPROM could be a small IC that is accessed with an
I2C or microwire interface (more about those in C h a p t e r 2). T h e tradeoffs here are:

9 Since each sensor carries its own calibration information, sensors and micro-
processor boards can be i n t e r c h a n g e d at will without affecting results. Spare
sensors can be calibrated and stocked without having to be m a t c h e d to a specific
system.
9 More m e m o r i e s are required, one for each sensor that needs calibration.

Finally, d i a g r a m C in Figure 1.1 takes this concept a step further, a d d i n g a

microcontroller to the sensor board, with the microcontroller p e r f o r m i n g the

System Design 3
 EEPROM OR
REMOTE
SENSOR # MICROPROCESSOR
FLASH MEMORY
WITH
CALIBRATION
CONSTANTS

REMOTE
SENSOR
# MICROPROCESSOR

EEPROM WITH
CALIBRATION
CONSTANTS

MICROCONTROLLER
WITH EEPROM FOR
SENSOR MICROPROCESSOR
CALIBRATION
CONSTANTS

Figure 1.1
Sensor calibration methods.

calibration and storing calibration data in an internal EEPROM or flash m e m o r y .

T h e tradeoffs here are:

9 T h e r e are m o r e processors and m o r e firmware to maintain. In some applica-

tions with rigorous software d o c u m e n t a t i o n r e q u i r e m e n t s (medical, military)
this may be a significant d e v e l o p m e n t cost.
9 No calibration effort is required by the main microprocessor. For a given real-
world condition such as t e m p e r a t u r e it will always get the same value, regard-
less of the sensor o u t p u t variation.
9 I f a sensor becomes unavailable or otherwise has to be changed in production, the
change can be m a d e transparent to the main microprocessor code, with all the
new characteristics of the new sensor handled in the remote microcontroller.

4 Analog Interfacing to Embedded Microprocessor Systems

 Another factor to consider in calibration is the h u m a n element. If a system
requires calibration of a sensor in the field, does the field technician need arms
twelve feet long to hold the calibration card in place and simultaneously reach the
"ENTER" key on the keyboard? Should a switch be placed near the sensor so
calibration can be accomplished without walking repeatedly a r o u n d a table to hit
a key or view the results on the display? Can the adjustment process be a u t o m a t e d
to minimize the n u m b e r of manual steps required? T h e m o r e manual adjust-
ments that are needed, the more opportunities there are for mistakes.

Bandwidth

Several years ago, I worked on an imaging application. This system was to

capture data using a charge coupled device (CCD) image sensor. We were
capturing 1024 pixels per scan. We had to capture items moving 150 inches
per second at a resolution of 200 pixels per inch. Each pixel was converted with
an 8-bit ADC, resulting in 1 byte per pixel. T h e data rate was theretbre
150 x 1024 x 200, or 30,720,000 bytes per second.
We planned to use the VME bus as the basis for the system. Each scan from the
CCD had to be read, normalized, filtered, and then converted to 1-bit-per-pixel
m o n o c h r o m e . During the meetings that were held to establish the system archi-
tecture, one of the engineers insisted that we pass all the data t h r o u g h the VME
bus. In those days, the VME bus had a m a x i m u m bandwidth specification of 40
megabytes per second, and very few systems could achieve the m a x i m u m theo-
retical bandwidth. T h e bandwidth we n e e d e d looked like this:

Read data from camera into system: 30.72 Mbytes/sec

Pass data to normalizer: 30.72 Mbytes/sec
Pass data to filter: 30.72 Mbytes/sec
Pass data to m o n o c h r o m e converter: 30.72 Mbytes/sec
Pass m o n o c h r o m e data to output: 3.84 Mbytes/sec

If you add all this up, you get 126.72 Mbytes/sec, well b e y o n d even the theore-
tical capability of the VME bus back then. More recently, I worked on a similar
imaging application that was i m p l e m e n t e d with digital signal processors (DSPs)
and multiple PCI buses, and one of the PCI buses was near its m a x i m u m
capability when all the features were added. T h e point is, know how much data
you have to push a r o u n d and what buses or data paths you are going to use. If
you are using a standard interface such as Ethernet or Firewire, be sure it will
s u p p o r t the total bandwidth required.

System Design 5
Processor Throughput

In many applications, the processor throughput is an important consideration. In

the imaging example just mentioned, most of the functionality was performed in
hardware because the available microprocessors could not keep up. As processor
speeds increase, more functionality is pushed into the software. There are several
key factors that you must consider to determine your throughput requirements.

Interrupts
How often must the interrupts occur, and how much processing must be performed
in each interrupt service routine (ISR)? What is the maximum allowable latency for
servicing an interrupt? Will interrupts need to be turned off for an extended length
of time, and how will that affect the latency of other interrupts? You may find that
you need two (or more) processors---one to handle high-speed interrupts with short
latency requirements but low complexity processing needs, and another to handle
low-rate interrupts with more complex processing requirements.

Interfaces
What must the system talk to? How will the data be passed around or get to the
outside world? How much hardware support will there be for the interface and
how much of the functionality will be performed in software? To take a simple
example, an IZc interface that is implemented on a microcontroller by flipping
bits in software will impact overall throughput more than an IzC interface that is
implemented in hardware. This issue will likely be related to the interrupt con-
siderations, because the interface will probably use interrupts. (If you don't know
what IZc is, it will be covered in Chapter 2.)

Hardware Support
An imaging application that has a direct memory access (DMA) controller to move
large amounts of data around will not need as much processor horsepower as one
that has to move the data in software. A processor that has to move the data in
software but has some kind of block-move instruction in the hardware will
probably be faster than one that has to have a series of instructions to construct
a loop. Similarly, if the CPU has an on-chip floating point unit (FPU) coprocessor,
then floating point operations will be much faster than they would be if they had
to be executed in software.

6 Analog Interfacing to Embedded Microprocessor Systems

Processing Requirements
If you are working on an imaging application, having a processor move the data
from one process (such as the camera interface logic) to another (such as filtering
logic) takes some degree of processing. If the processor has to actually implement
the filtering algorithm in software, this takes a lot more processing horsepower. It
is amazing how often systems are designed with little or no analysis of the a m o u n t
of processing the CPU actually has to do.

Operating System Requirements

If you use an operating system (OS), how long will interrupts be turned off?. Is
this compatible with the interrupt latency requirements? What if the OS occa-
sionally stops processing to spend a few seconds thrashing the hard disk? Will this
cause data to be lost? Does the system have real-time requirements that will make
a real-time operating system necessary?

Language~Compiler
If you plan to use an object-oriented language such as C + + , what happens when
the CPU has to do garbage collection on the memory? Will data be lost? Does
choosing this approach mean you have to go from a 100 MHz processor to a
1 GHz processor just to keep the garbage collection interval short?

A voiding Excess Speed

Choosing a bus architecture and a processor that are fast enough to do the job is
important, but it can also be important to avoid too much speed. It may not seem
logical that you wouldn't always want the fastest bus and the fastest microproces-
sor, but there are applications where that is exactly the case. T h e r e are two basic
reasons for this: cost and electromagnetic compatibility (EMC).

Cost
The PC/104 standard defines mechanical and electrical characteristics of PC
boards, optimized for e m b e d d e d applications. PC/104 CPU boards come with
the original PC/104 bus, which has electrical and timing characteristics similar to
the ISA bus used in personal computers and is capable of data transfers in the
5 Mbytes/sec range. Many CPU boards also have the PC/104 Plus bus, which has
characteristics similar to the much faster (133 Mbytes/sec) PCI bus. Although it
might seem that the faster bus is always preferred, it is often less expensive to

System Design 7
design a peripheral board for the PC/104 bus than for the PC/104 Plus. PC/104,
due to the slower clock rates, allows longer traces and simpler logic. If you have a
relatively large analog I/O board plugged into a PC/104 CPU board, the relaxed
timing constraints of PC/104 may make layout easier. Many low-volume products
simply do not sell enough units to justify the higher development costs associated
with PC/104 Plus. Of course, this assumes that the PC/104 bus will support the
necessary data rates. Similar considerations apply to other buses, such as PCI and
Compact PCI.

EMC
Almost every microprocessor-based design will have to undergo EMC testing
before it can be sold in the United States or Europe. EMC regulations limit the
a m o u n t of energy the product can emit, to prevent interference with other
equipment such as televisions and radios. Generally, the higher the clock rates
are, the more emissions the equipment generates. Current EMC standards test
radiated emissions in the frequency range between 30 MHz and 1 GHz. A pro-
cessor r u n n i n g with a 6 MHz clock will not have any fundamental emissions in
this range; the only frequencies in the test range will be those from the fifth and
higher harmonics of the processor clock. The higher harmonics typically have
less energy. On the other hand, a 33 MHz processor will produce energy in the
test band from its fundamental frequency and higher. In addition, a faster
processor clock rate means faster logic with faster edges and correspondingly
higher energy in the harmonics. Although using a 6 MHz example in an era of
2 GHz Pentiums may seem archaic, it does illustrate the point. EMC concerns are
a valid reason to limit bus and processor speeds only to what is actually needed for
the application. The caution here is not to limit the design too much. If the
processor can just barely keep up with the application, there is no margin left
to fix problems or add enhancements.

Other System Considerations

Peripheral Hardware
An imaging system was having problems with lost data. This particular system
buffered considerable image data on a hard disk drive. The problem was traced
to the disk drive; the drive would just stop accepting data for a while and the
image buffers would overflow. It turned out that this particular drive had a
thermal compensation feature that required the on-drive CPU to "go away" for
a few tens of milliseconds every so often. The application required continuous

8 Analog Interfacing to Embedded Microprocessor Systems

access to the drive. Be sure the p e r i p h e r a l h a r d w a r e is compatible with your
application and does not introduce problems.

Shared Interfaces
W h a t is the impact of shared interfaces? For example, if you are continuously
buffering data from two different image cameras on two disk drives, a single IDE
interface may not be fast e n o u g h . You may need separate IDE interfaces for the
two drives so they can operate i n d e p e n d e n t l y , or you may n e e d to go to an
interface with higher p e r f o r m a n c e . Similarly, will 10-baseT E t h e r n e t handle all
your data, or will you need 100-baseT? Look at all the data on all the interfaces
and m a k e sure the b a n d w i d t h you need is there.

Task Priorities
T h e IBM PC architecture has been used for all kinds of applications. It is a
well-documented s t a n d a r d with an e n o r m o u s n u m b e r of compatible software
packages available. But it has some drawbacks, including the non-real-time
n a t u r e of the standard Windows o p e r a t i n g system. You have probably experi-
enced having your PC stop r e s p o n d i n g for a few seconds while it thrashes the
hard disk for some u n k n o w n reason. If you are typing a d o c u m e n t on a word
processor, this is a m i n o r a n n o y a n c e n w h a t e v e r you typed is c a p t u r e d (as long
as it isn't too m a n y characters) and shows up on the screen w h e n e v e r the
o p e r a t i n g system gets back to processing the keyboard. What h a p p e n s if you
are getting a continuous stream of data from an audio or video device when
this happens? If your system isn't constructed to p e r m i t your data stream to
have a high priority, some data may be lost. If you are using a PC-like
architecture, be sure the h a r d w a r e and o p e r a t i n g system software will s u p p o r t
the things you need to do.

Hardware Requirements
Do you need a floating-point processor to do calculations on the data you will be
processing? If so, you won't be able to use a simple 8-bit processor, you will need
at least a 486-class machine. Does the data rate require a processor with a DMA
controller to keep up? This limits your potential CPU selections to just a few. In
some cases, you can make system adaptations that will lower h a r d w a r e costs, as
the following e x a m p l e will illustrate.
I m a g i n e that you have a m o t o r - d r i v e n wheel that p r o d u c e s an i n t e r r u p t to
your processor every 20 ~ of rotation (see Figure 1.2). T h e m o t o r runs at varying
speeds and the processor has to schedule some event, such as activating a solenoid
to o p e n a valve, some n u m b e r of degrees after the i n t e r r u p t occurs. T h e 20 ~

System Design 9
 20 DEGREES
CPU INTERRUPT ~1 OF ROTATION I~
FROM SENSOR
ON ROTATING
WHEEL

CPU HAS TO SCHEDULE

SOME EVENTTO
OCCUR SOME NUMBER
OF DEGREESAFTER
INTERRUPT
TIMING MARKSARE SPACED
20 DEGREESAPARTON
WHEEL.

Figure 1.2
Rotating wheel timing.

interrupts will occur 3.3 ms a p a r t if the wheel spins at 1000 r p m , a n d 666 ~tS apart
if the wheel spins at 5 0 0 0 r p m . If the processor uses a timer to m e a s u r e the
rotation speed (time between interrupts), and if the timer runs at 1 MHz, then
the timer will i n c r e m e n t 3300 counts between interrupts at 1000 r p m , and 666
counts at 5000 r p m .
Say that the CPU has to o p e n o u r hypothetical solenoid w h e n the wheel has
rotated 5 ~ past one of the interrupts, as shown in Figure 1.2. T h e formula for
calculating the timer value (how m u c h must be a d d e d to the c u r r e n t count for a
5 ~ delay) looks like this:

5 degrees delay N u m b e r of
T i m e r i n c r e m e n t value =
20 d e g r e e s / i n t e r r u p t x timer counts per i n t e r r u p t

So at 1000 r p m , the 5 ~ delay is 825 timer counts, and at 5000 r p m , the delay is
166 counts. T h e p r o b l e m with this a p p r o a c h in an e m b e d d e d system is the need
to divide by 20 in the formula. Division is a t i m e - c o n s u m i n g task to p e r f o r m in
software, and this a p p r o a c h m i g h t require that you choose a processor with
h a r d w a r e divide instruction.
If we change o u r m e a s u r e m e n t system so that the 20 ~ divisions are divided into
binary values, the m a t h gets easier. Say that we decide to divide the 20 ~ divisions
into 32 equal parts, each part being 0.625 degrees. We'll call these increments
units just so we have a n a m e for them. T h e 5 ~ i n c r e m e n t is now 5/0.625 or 8 units.
Now o u r formula looks like this:

8 units N u m b e r of
T i m e r i n c r e m e n t value =
32 units per i n t e r r u p t x timer counts per i n t e r r u p t

10 Analog Interfacing to Embedded Microprocessor Systems

 This gives us the same result as before (825 at 1000 rpm, 166 at 5000 rpm), but
division by 32 can be p e r f o r m e d with a simple shift operation instead of a
complex software algorithm. A change like this may mean the difference between
a simple 8-bit microcontroller and a m o r e complex and expensive microproces-
sor. All we did was change from m e a s u r i n g degrees of rotation to m e a s u r i n g
something that is easier to calculate.

Word Width
If you are connecting a processor to a 12-bit ADC, you will probably want a 16-bit
processor instead of an 8-bit processor. While you can p e r f o r m 16-bit operations
on an 8-bit CPU, it usually requires multiple instructions and has o t h e r limita-
tions. Unless the processor is simply passing the data on to some other part of the
system, you will want to match the CPU to the devices with which it must inter-
face. Similarly, if you will be p e r f o r m i n g calculations to 32-bit accuracy, you will
want to consider a CPU with at least 16-bit and probably 32-bit word width to
make computation easier and faster.

Interfaces
Be sure that interface conditions that are unusual but normal d o n ' t cause d a m a g e
to any part of the system. For instance, a microprocessor board may connect to a
m o t o r control b o a r d with a cable. What h a p p e n s if the service e n g i n e e r leaves the
cable u n p l u g g e d and turns the system on? Will the motors remain stationary, or
will they r u n out of control? Make sure that issues like this are addressed.

Sample Rate and Aliasing

Figure 1.3 shows a sinusoidal input signal and an ADC that is sampling at a slower
rate than the signal is changing. If the system m e a s u r i n g this system a s s u m e d it
was measuring a sinusoid of some frequency, it would conclude that it was
m e a s u r i n g a sinusoid exactly half the frequency of the real input. This is called
aliasing, and it can occur any time that the input frequency is a multiple of the
sample frequency.
Also shown in Figure 1.3 is a n o t h e r input waveform that is not a sinusoid. In
this case, the system doesn't assume it is sampling a sine, so it just stores the
samples as they are read. As you can see, the resulting pattern of data values does
not match the input at all.
Any system must be designed so that it can keep up with whatever it is
measuring. This includes the speed at which the ADC can collect samples and

System Design 11
 DOTSINDICATESAMPLEDVOLTAGES
SAMPLED
SIGNAL

ADC SAMPLE
POINTS I I

RESULTING ~ ~ ~ , ~

ANOTHER
SAMPLED
WAVEFORM

WHATTHE
SYSTEM
REALLY
MEASURES

Figure 1.3
Aliasing.

the speed at which the microprocessor can process them. If the input frequency
will be greater than the measurement capability of the system, there are three
ways to handle it"

1. Speed up the system to match the input.

2. Filter out high-frequency components with external hardware ahead of the
ADC measuring the signal.
3. Filter out or ignore high-frequency components in software. This sounds
sillymhow do you filter something faster than you can measure? But if the
valid input range is known, such as the n u m b e r of cars entering a parking lot
over any given time, then bogus inputs may be detectable. In this example, any
input frequency greater than a couple per second can be assumed to be the
result of noise or a faulty sensormreal cars don't enter parking lots that fast.

Good system design depends on choosing the right tradeoffs between proces-
sor speed, system cost, and ease of manufacture.

12 Analog Interfacing to Embedded Microprocessor Systems