Inside the embedded system

Inside the embedded system

Processor

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

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.

Peripherals

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:

•                                                                         Binary outputs

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.

•                                                                         Serial outputs

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.

•                                                                        Analogue values

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

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.

Software

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 environment

•                                                                        The applications software itself

•                                                                        Error handling

•                                                                        Debug and maintenance support.

Algorithms

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 bodies.

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 book.

Examples

This section will go through some example embedded systems and briefly outline the type of functionality that each offers.

Microcontroller

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 forms:

•                                                                         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 release version.

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 production runs

•                                                                         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 production runs

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.

Expanded microcontroller

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

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.

Board based

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.