Inside the embedded system
The main criteria for the processor is: can it provide the processing
power needed to perform the tasks within the system? This seems obvious but it
frequently occurs that the tasks are either underestimated in terms of their
size and/or complexity or that creeping elegance expands the specification to
beyond the proces-sor’s capability.
In many cases, these types of problems are compounded by the performance
measurement used to judge the processor. Bench-marks may not be representative
of the type of work that the system is doing. They may execute completely out
of cache memory and thus give an artificially high performance level which the
final system cannot meet because its software does not fit in the cache. The
software overheads for high level languages, operating sys-tems and interrupts
may be higher than expected. These are all issues that can turn a paper design
into failed reality.
While processor performance is essential and forms the first gating
criterion, there are others such as cost — this should be system cost and not
just the cost of the processor in isolation, power consumption, software tools
and component availability and so on. These topics are discussed in more detail
in Chapter 2.
Memory is an important part of any embedded system design and is heavily
influenced by the software design, and in turn may dictate how the software is
designed, written and developed. These topics will be addressed in more detail
later on in this book. As a way of introduction, memory essentially per-forms
two functions within an embedded system:
It provides storage for the
software that it will run
At a minimum, this will take the form of some non-volatile memory that
retains its contents when power is removed. This can be on-chip read only
memory (ROM) or external EPROM. The software that it contains might be the
com-plete program or an initialisation routine that obtains the full software
from another source within or outside of the system. This initialisation
routine is often referred to as a bootstrap program or routine. PC boards that
have embed-ded processors will often start up using software stored in an
onboard EPROM and then wait for the full software to be downloaded from the PC
across the PC expansion bus.
It provides storage for data such
as program variables and intermediate results, status information and any other
data that might be created throughout the operation
Software needs some memory to store variables and to manage software
structures such as stacks. The amount of memory that is needed for variables is
frequently less than that needed for the actual program. With RAM being more
expensive than ROM and non-volatile, many embedded systems and in particular,
microcontrollers, have small amounts of RAM compared to the ROM that is
available for the program. As a result, the software that is written for such
systems often has to be written to minimise RAM usage so that it will fit
within the memory resources placed upon the design. This will often mean the
use of compilers that produce ROMable code that does not rely on being resident
in RAM to execute. This is discussed in more detail in Chapter 3.
An embedded system has to communicate with the outside world and this is
done by peripherals. Input peripherals are usually associated with sensors that
measure the external environ-ment and thus effectively control the output operations
that the embedded system performs. In this way, an embedded system can be
modelled on a three-stage pipeline where data and information input into the
first stage of the pipeline, the second stage processes it before the third
stage outputs data.
If this model is then applied to a motor controller, the inputs would be
the motor’s actual speed and power consumption, and the speed required by the
operator. The outputs would be a pulse width modulated waveform that controls
the power to the motor and hence the speed and an output to a control panel
showing the current speed. The middle stage would be the software that
processed the inputs and adjusts the outputs to achieve the re-quired engine
speed. The main types of peripherals that are used include:
These are simple external pins whose logic state can be controlled by
the processor to either be a logic zero (off) or a logic one (on). They can be
used individually or grouped together to create parallel ports where a group of
bits can be input or output simultaneously.
These are interfaces that send or receive data using one or two pins in
a serial mode. They are less complex to connect but are more complicated to
program. A parallel port looks very similar to a memory location and is easier
to visualise and thus use. A serial port has to have data loaded into a
register and then a start command issued. The data may also be augmented with
additional information as required by the protocol.
While processors operate in the digital domain, the natural world does
not and tends to orientate to analogue values. As a result, interfaces between
the system and the external environment need to be converted from analogue to
digital and vice versa.
Displays are becoming important and can vary from simple LEDs and seven
segment displays to small alpha-numeric LCD panels.
Time derived outputs
Timers and counters are probably the most commonly used functions within
an embedded system.
The software components within an embedded system often encompasses the
technology that adds value to the system and defines what it does and how well
it does it. The software can consist of several different components:
Initialisation and configuration
Operating system or run-time
The applications software itself
Debug and maintenance support.
Algorithms are the key constituents of the software that makes an
embedded system behave in the way that it does. They can range from
mathematical processing through to models of the external environment which are
used to interpret information from external sensors and thus generate control
signals. With the digital technology in use today such as MP3 and DVD players,
the algorithms that digitally encode the analogue data are defined by standards
While this standardisation could mean that the importance of selecting
an algorithm is far less than it might be thought, the reality is far
different. The focus on getting the right implementa-tion is important since,
for example, it may allow the same func-tion to be executed on cheaper
hardware. As most embedded systems are designed to be commercially successful,
this selection process is very important. Defining and implementing the correct
algorithm is a critical operation and is described through several examples in
This section will go through some example embedded systems and briefly
outline the type of functionality that each offers.
Microcontrollers can be considered as self-contained sys-tems with a
processor, memory and peripherals so that in many cases all that is needed to
use them within an embedded system is to add software. The processors are
usually based on 8 bit stack-based architectures such as the MC6800 family.
There are 4 bit versions available such as the National COP series which
further reduce the processing power and reduce cost even further. These are
limited in their functionality but their low cost has meant that they are used
in many obscure applications. Microcontrollers are usually available in several
Devices for prototyping or low
volume production runs
These devices use non-volatile memory to allow the soft-ware to be
downloaded and returned in the device. UV erasable EPROM used to be the
favourite but EEPROM is also gaining favour. Some microcontrollers used a
special package with a piggyback socket on top of the package to allow an
external EPROM to be plugged in for prototyping. This memory technology
replaces the ROM on the chip allowing software to be downloaded and debugged.
The device can be reprogrammed as needed until the software reaches its final
The use of non-volatile memory also makes these devices suitable for low
volume production runs or where the software may need customisation and thus
preventing moving to a ROMed version.
These devices are sometimes referred to as umbrella de-vices with a
single device capable of providing prototyping support for a range of other
controllers in the family.
Devices for low to medium volume
In the mid-1980s, a derivative of
the prototype device appeared on the market called the one time programmable or
OTP. These devices use EPROM instead of the ROM but instead of using the
ceramic package with a window to allow the device to be erased, it was packaged
in a cheaper plastic pack and thus was only capable of programming a single
time — hence the name. These devices are cheaper than the prototype versions
but still have the programming disadvantage. However, their lower cost has made
them a suitable alternative to producing a ROM device. For low to medium
production quantities, they are cost effective and offer the ability to
customise software as necessary.
Devices for high volume
For high volumes, microcontrollers can be built already programmed with
software in the ROM. To do this a customer supplies the software to the
manufacturer who then creates the masks necessary to create the ROM in the
device. This process is normally done on partly processed silicon wafers to
reduce the turnaround time. The advan-tage for the customer is that the costs
are much lower than using prototyping or OTP parts and there is no program-ming
time or overhead involved. The downside is that there is usually a minimum
order based on the number of chips that a wafer batch can produce and an
upfront mask charge. The other major point is that once in ROM, the software
cannot be changed and therefore customisation or bug fixing would have to wait
until the next order or involve scrapping all the devices that have been made.
It is possible to offer some customisation by including different software
modules and selecting the required ones on the basis of a value read into the
device from an external port but this does consume memory which can increase
the costs. Some controllers can provide some RAM that can be used to patch the
ROM without the need for a new mask set.
The choice of memory sizes and partitioning is usually a major
consideration. Some applications require more memory or peripherals than are
available on a standard part. Most microcontroller families have parts that
support external expan-sion and have an external memory and/or I/O bus which
can allow the designer to put almost any configuration together. This is often
done by using a parallel port as the interface instead of general-purpose I/O.
Many of the higher performance microcontrollers are adopting this approach.
In the example shown on the previous page, the microcontroller has an
expanded mode that allows the parallel ports A and B to be used as byte wide
interfaces to external RAM and ROM. In this type of configuration, some microcontrollers
disable access to the internal memory while others still allow it.
Microprocessor-based embedded systems originally took existing
general-purpose processors such as the MC6800 and 8080 devices and constructed
systems around them using external peripherals and memory. The use of
processors in the PC market continued to provide a series of faster and faster
processors such as the MC68020, MC68030 and MC68040 devices from Motorola and
the 80286, 80386, 80486 and Pentium devices from Intel. These CISC
architectures have been complemented with RISC proces-sors such as the PowerPC,
MIPS and others. These systems offer more performance than is usually available
from a traditional microcontroller.
However, this is beginning to change. There has been the development of
integrated microprocessors where the processor is combined with peripherals
such as parallel and serial ports, DMA controllers and interface logic to
create devices that are more suitable for embedded systems by reducing the
hardware design task and costs. As a result, there has been almost a parallel
development of these integrated processors along with the desk-top processors.
Typically, the integrated processor will use a processor generation that is one
behind the current generation. The reason is dependent on silicon technology
and cost. By using the previous generation which is smaller, it frees up
silicon area on the die to add the peripherals and so on.
So far, the types of embedded systems that we have consid-ered have
assumed that the hardware needs to be designed, built and debugged. An
alternative is to use hardware that has already been built and tested such as
board-based systems as provided by PCs and through international board
standards such as VMEbus. The main advantage is the reduced work load and the
availability of ported software that can simply be utilised with very little
effort. The disadvantages are higher cost and in some cases restrictions in the
functionality that is available.