Embedded system

An embedded system is a specialized comput er syst em—a combinat ion of a comput er

processor, comput er memory, and input /out put peripheral devices—t hat has a dedicat ed funct ion
wit hin a larger mechanical or elect ronic syst em.[1][2] It is embedded as part of a complet e device
oft en including elect rical or elect ronic hardware and mechanical part s. Because an embedded
syst em t ypically cont rols physical operat ions of t he machine t hat it is embedded wit hin, it oft en
has real-t ime comput ing const raint s. Embedded syst ems cont rol many devices in common use.[3]
In 2009, it was est imat ed t hat ninet y-eight percent of all microprocessors manufact ured were
used in embedded syst ems.[4]

An embedded system on a plug-in card with

processor, memory, power supply, and
external interfaces

Modern embedded syst ems are oft en based on microcont rollers (i.e. microprocessors wit h
int egrat ed memory and peripheral int erfaces), but ordinary microprocessors (using ext ernal chips
for memory and peripheral int erface circuit s) are also common, especially in more complex
syst ems. In eit her case, t he processor(s) used may be t ypes ranging from general purpose t o
t hose specialized in a cert ain class of comput at ions, or even cust om designed for t he applicat ion
at hand. A common st andard class of dedicat ed processors is t he digit al signal processor (DSP).

Since t he embedded syst em is dedicat ed t o specific t asks, design engineers can opt imize it t o
reduce t he size and cost of t he product and increase it s reliabilit y and performance. Some
embedded syst ems are mass-produced, benefit ing from economies of scale.

Embedded syst ems range in size from port able personal devices such as digit al wat ches and
MP3 players t o bigger machines like home appliances, indust rial assembly lines, robot s, t ransport
vehicles, t raffic light cont rollers, and medical imaging syst ems. Oft en t hey const it ut e
subsyst ems of ot her machines like avionics in aircraft and ast rionics in spacecraft . Large
inst allat ions like fact ories, pipelines, and elect rical grids rely on mult iple embedded syst ems
net worked t oget her. Generalized t hrough soft ware cust omizat ion, embedded syst ems such as
programmable logic cont rollers frequent ly comprise t heir funct ional unit s.
Embedded syst ems range from t hose low in complexit y, wit h a single microcont roller chip, t o
very high wit h mult iple unit s, peripherals and net works, which may reside in equipment racks or
across large geographical areas connect ed via long-dist ance communicat ions lines.

History

Background

The origins of t he microprocessor and t he microcont roller can be t raced back t o t he MOS
int egrat ed circuit , which is an int egrat ed circuit chip fabricat ed from MOSFETs (met al–oxide–
semiconduct or field-effect t ransist ors) and was developed in t he early 1960s. By 1964, MOS
chips had reached higher t ransist or densit y and lower manufact uring cost s t han bipolar chips.
MOS chips furt her increased in complexit y at a rat e predict ed by Moore's law, leading t o large-
scale int egrat ion (LSI) wit h hundreds of t ransist ors on a single MOS chip by t he lat e 1960s. The
applicat ion of MOS LSI chips t o comput ing was t he basis for t he first microprocessors, as
engineers began recognizing t hat a complet e comput er processor syst em could be cont ained on
several MOS LSI chips.[5]

The first mult i-chip microprocessors, t he Four-Phase Syst ems AL1 in 1969 and t he Garret t
AiResearch MP944 in 1970, were developed wit h mult iple MOS LSI chips. The first single-chip
microprocessor was t he Int el 4004, released in 1971. It was developed by Federico Faggin, using
his silicon-gat e MOS t echnology, along wit h Int el engineers Marcian Hoff and St an Mazor, and
Busicom engineer Masat oshi Shima.[6]

Development

One of t he first recognizably modern embedded syst ems was t he Apollo Guidance Comput er,
developed ca. 1965 by Charles St ark Draper at t he MIT Inst rument at ion Laborat ory. At t he
project 's incept ion, t he Apollo guidance comput er was considered t he riskiest it em in t he Apollo
project as it employed t he t hen newly developed monolit hic int egrat ed circuit s t o reduce t he
comput er's size and weight .

An early mass-produced embedded syst em was t he Aut onet ics D-17 guidance comput er for t he
Minut eman missile, released in 1961. When t he Minut eman II went int o product ion in 1966, t he D-
17 was replaced wit h a new comput er t hat represent ed t he first high-volume use of int egrat ed
circuit s.

Since t hese early applicat ions in t he 1960s, embedded syst ems have come down in price and
t here has been a dramat ic rise in processing power and funct ionalit y. An early microprocessor, t he
Int el 4004 (released in 1971), was designed for calculat ors and ot her small syst ems but st ill
required ext ernal memory and support chips. By t he early 1980s, memory, input and out put
syst em component s had been int egrat ed int o t he same chip as t he processor forming a
microcont roller. Microcont rollers find applicat ions where a general-purpose comput er would be
t oo cost ly. As t he cost of microprocessors and microcont rollers fell, t he prevalence of
embedded syst ems increased.

A comparat ively low-cost microcont roller may be programmed t o fulfill t he same role as a large
number of separat e component s. Wit h microcont rollers, it became feasible t o replace, even in
consumer product s, expensive knob-based analog component s such as pot ent iomet ers and
variable capacit ors wit h up/down but t ons or knobs read out by a microprocessor. Alt hough in t his
cont ext an embedded syst em is usually more complex t han a t radit ional solut ion, most of t he
complexit y is cont ained wit hin t he microcont roller it self. Very few addit ional component s may be
needed and most of t he design effort is in t he soft ware. Soft ware prot ot ype and t est can be
quicker compared wit h t he design and const ruct ion of a new circuit not using an embedded
processor.

Applications

Embedded Computer Sub-Assembly for

Accupoll Electronic Voting Machine[7]

Embedded syst ems are commonly found in consumer, indust rial, aut omot ive, home appliances,
medical, t elecommunicat ion, commercial, aerospace and milit ary applicat ions.

Telecommunicat ions syst ems employ numerous embedded syst ems from t elephone swit ches
for t he net work t o cell phones at t he end user. Comput er net working uses dedicat ed rout ers and
net work bridges t o rout e dat a.

Consumer elect ronics include MP3 players, t elevision set s, mobile phones, video game consoles,
digit al cameras, GPS receivers, and print ers. Household appliances, such as microwave ovens,
washing machines and dishwashers, include embedded syst ems t o provide flexibilit y, efficiency
and feat ures. Advanced heat ing, vent ilat ion, and air condit ioning (HVAC) syst ems use net worked
t hermost at s t o more accurat ely and efficient ly cont rol t emperat ure t hat can change by t ime of
day and season. Home aut omat ion uses wired and wireless net working t hat can be used t o
cont rol light s, climat e, securit y, audio/visual, surveillance, et c., all of which use embedded devices
for sensing and cont rolling.

Transport at ion syst ems from flight t o aut omobiles increasingly use embedded syst ems. New
airplanes cont ain advanced avionics such as inert ial guidance syst ems and GPS receivers t hat
also have considerable safet y requirement s. Spacecraft rely on ast rionics syst ems for t raject ory
correct ion. Various elect ric mot ors — brushless DC mot ors, induct ion mot ors and DC mot ors —
use elect ronic mot or cont rollers. Aut omobiles, elect ric vehicles, and hybrid vehicles increasingly
use embedded syst ems t o maximize efficiency and reduce pollut ion. Ot her aut omot ive safet y
syst ems using embedded syst ems include ant i-lock braking syst em (ABS), elect ronic st abilit y
cont rol (ESC/ESP), t ract ion cont rol (TCS) and aut omat ic four-wheel drive.

Medical equipment uses embedded syst ems for monit oring, and various medical imaging
(posit ron emission t omography (PET), single-phot on emission comput ed t omography (SPECT),
comput ed t omography (CT), and magnet ic resonance imaging (MRI) for non-invasive int ernal
inspect ions. Embedded syst ems wit hin medical equipment are oft en powered by indust rial
comput ers.[8]

Embedded syst ems are used for safet y-crit ical syst ems in aerospace and defense indust ries.
Unless connect ed t o wired or wireless net works via on-chip 3G cellular or ot her met hods for IoT
monit oring and cont rol purposes, t hese syst ems can be isolat ed from hacking and t hus be more
secure. For fire safet y, t he syst ems can be designed t o have a great er abilit y t o handle higher
t emperat ures and cont inue t o operat e. In dealing wit h securit y, t he embedded syst ems can be
self-sufficient and be able t o deal wit h cut elect rical and communicat ion syst ems.

Miniat ure wireless devices called mot es are net worked wireless sensors. Wireless sensor
net working makes use of miniat urizat ion made possible by advanced int egrat ed circuit (IC) design
t o couple full wireless subsyst ems t o sophist icat ed sensors, enabling people and companies t o
measure a myriad of t hings in t he physical world and act on t his informat ion t hrough monit oring
and cont rol syst ems. These mot es are complet ely self-cont ained and will t ypically run off a
bat t ery source for years before t he bat t eries need t o be changed or charged.

Characteristics

Embedded syst ems are designed t o perform a specific t ask, in cont rast wit h general-purpose
comput ers designed for mult iple t asks. Some have real-t ime performance const raint s t hat must
be met , for reasons such as safet y and usabilit y; ot hers may have low or no performance
requirement s, allowing t he syst em hardware t o be simplified t o reduce cost s.
Embedded syst ems are not always st andalone devices. Many embedded syst ems are a small
part wit hin a larger device t hat serves a more general purpose. For example, t he Gibson Robot
Guit ar feat ures an embedded syst em for t uning t he st rings, but t he overall purpose of t he Robot
Guit ar is t o play music.[9] Similarly, an embedded syst em in an aut omobile provides a specific
funct ion as a subsyst em of t he car it self.

e-con Systems eSOM270 & eSOM300

Computer on Modules

The program inst ruct ions writ t en for embedded syst ems are referred t o as firmware, and are
st ored in read-only memory or flash memory chips. They run wit h limit ed comput er hardware
resources: lit t le memory, small or non-exist ent keyboard or screen.

User interfaces

Embedded system text user interface

using MicroVGA[nb 1]

Embedded syst ems range from no user int erface at all, in syst ems dedicat ed t o one t ask, t o
complex graphical user int erfaces t hat resemble modern comput er deskt op operat ing syst ems.
Simple embedded devices use but t ons, light -emit t ing diodes (LED), graphic or charact er liquid-
cryst al displays (LCD) wit h a simple menu syst em. More sophist icat ed devices t hat use a
graphical screen wit h t ouch sensing or screen-edge soft keys provide flexibilit y while minimizing
space used: t he meaning of t he but t ons can change wit h t he screen, and select ion involves t he
nat ural behavior of point ing at what is desired.
Some syst ems provide user int erface remot ely wit h t he help of a serial (e.g. RS-232) or net work
(e.g. Et hernet ) connect ion. This approach ext ends t he capabilit ies of t he embedded syst em,
avoids t he cost of a display, simplifies t he board support package (BSP) and allows designers t o
build a rich user int erface on t he PC. A good example of t his is t he combinat ion of an embedded
HTTP server running on an embedded device (such as an IP camera or a net work rout er). The
user int erface is displayed in a web browser on a PC connect ed t o t he device.

Processors in embedded systems

Examples of propert ies of t ypical embedded comput ers when compared wit h general-purpose
count erpart s, are low power consumpt ion, small size, rugged operat ing ranges, and low per-unit
cost . This comes at t he expense of limit ed processing resources.

Numerous microcont rollers have been developed for embedded syst ems use. General-purpose
microprocessors are also used in embedded syst ems, but generally, require more support
circuit ry t han microcont rollers.

Ready-made computer boards

PC/104 and PC/104+ are examples of st andards for ready-made comput er boards int ended for
small, low-volume embedded and ruggedized syst ems. These are most ly x86-based and oft en
physically small compared t o a st andard PC, alt hough st ill quit e large compared t o most simple
(8/16-bit ) embedded syst ems. They may use DOS, FreeBSD, Linux, Net BSD, OpenHarmony or an
embedded real-t ime operat ing syst em (RTOS) such as MicroC/OS-II, QNX or VxWorks.

In cert ain applicat ions, where small size or power efficiency are not primary concerns, t he
component s used may be compat ible wit h t hose used in general-purpose x86 personal
comput ers. Boards such as t he VIA EPIA range help t o bridge t he gap by being PC-compat ible
but highly int egrat ed, physically smaller or have ot her at t ribut es making t hem at t ract ive t o
embedded engineers. The advant age of t his approach is t hat low-cost commodit y component s
may be used along wit h t he same soft ware development t ools used for general soft ware
development . Syst ems built in t his way are st ill regarded as embedded since t hey are int egrat ed
int o larger devices and fulfill a single role. Examples of devices t hat may adopt t his approach are
aut omat ed t eller machines (ATM) and arcade machines, which cont ain code specific t o t he
applicat ion.

However, most ready-made embedded syst ems boards are not PC-cent ered and do not use t he
ISA or PCI busses. When a syst em-on-a-chip processor is involved, t here may be lit t le benefit t o
having a st andardized bus connect ing discret e component s, and t he environment for bot h
hardware and soft ware t ools may be very different .
One common design st yle uses a small syst em module, perhaps t he size of a business card,
holding high densit y BGA chips such as an ARM-based syst em-on-a-chip processor and
peripherals, ext ernal flash memory for st orage, and DRAM for runt ime memory. The module
vendor will usually provide boot soft ware and make sure t here is a select ion of operat ing
syst ems, usually including Linux and some real-t ime choices. These modules can be
manufact ured in high volume, by organizat ions familiar wit h t heir specialized t est ing issues, and
combined wit h much lower volume cust om mainboards wit h applicat ion-specific ext ernal
peripherals. Prominent examples of t his approach include Arduino and Raspberry Pi.

ASIC and FPGA SoC solutions

A syst em on a chip (SoC) cont ains a complet e syst em - consist ing of mult iple processors,
mult ipliers, caches, even different t ypes of memory and commonly various peripherals like
int erfaces for wired or wireless communicat ion on a single chip. Oft en graphics processing unit s
(GPU) and DSPs are included such chips. SoCs can be implement ed as an applicat ion-specific
int egrat ed circuit (ASIC) or using a field-programmable gat e array (FPGA) which t ypically can be
reconfigured.

ASIC implement at ions are common for very-high-volume embedded syst ems like mobile phones
and smart phones. ASIC or FPGA implement at ions may be used for not -so-high-volume
embedded syst ems wit h special needs in kind of signal processing performance, int erfaces and
reliabilit y, like in avionics.

Peripherals

A close-up of the SMSC LAN91C110

(SMSC 91x) chip, an embedded Ethernet
chip

Embedded syst ems t alk wit h t he out side world via peripherals, such as:

Serial communicat ion int erfaces (SCI): RS-232, RS-422, RS-485, et c.

Synchronous Serial Int erface: I2C, SPI, SSC and ESSI (Enhanced Synchronous Serial Int erface)

Universal Serial Bus (USB)

 Media cards (SD cards, Compact Flash, et c.)

Net work int erface cont roller: Et hernet , WiFi, et c.

Fieldbuses: CAN bus, LIN-Bus, PROFIBUS, et c.

Timers: Phase-locked loops, programmable int erval t imers

General Purpose Input /Out put (GPIO)

Analog-t o-digit al and digit al-t o-analog convert ers

Debugging: JTAG, In-syst em programming, background debug mode int erface port , BITP, and
DB9 port s.

Tools

As wit h ot her soft ware, embedded syst em designers use compilers, assemblers, and debuggers
t o develop embedded syst em soft ware. However, t hey may also use more specific t ools:

In circuit debuggers or emulat ors (see next sect ion).

Ut ilit ies t o add a checksum or CRC t o a program, so t he embedded syst em can check if t he
program is valid.

For syst ems using digit al signal processing, developers may use a comput at ional not ebook t o
simulat e t he mat hemat ics.

Syst em-level modeling and simulat ion t ools help designers t o const ruct simulat ion models of a
syst em wit h hardware component s such as processors, memories, DMA, int erfaces, buses and
soft ware behavior flow as a st at e diagram or flow diagram using configurable library blocks.
Simulat ion is conduct ed t o select t he right component s by performing power vs. performance
t rade-offs, reliabilit y analysis and bot t leneck analysis. Typical report s t hat help a designer t o
make archit ect ure decisions include applicat ion lat ency, device t hroughput , device ut ilizat ion,
power consumpt ion of t he full syst em as well as device-level power consumpt ion.

A model-based development t ool creat es and simulat es graphical dat a flow and UML st at e
chart diagrams of component s like digit al filt ers, mot or cont rollers, communicat ion prot ocol
decoding and mult i-rat e t asks.

Cust om compilers and linkers may be used t o opt imize specialized hardware.

An embedded syst em may have it s own special language or design t ool, or add enhancement s
t o an exist ing language such as Fort h or Basic.

Anot her alt ernat ive is t o add a RTOS or embedded operat ing syst em

Modeling and code generat ing t ools oft en based on st at e machines

Soft ware t ools can come from several sources:

 Soft ware companies t hat specialize in t he embedded market

Port ed from t he GNU soft ware development t ools

Somet imes, development t ools for a personal comput er can be used if t he embedded
processor is a close relat ive t o a common PC processor

Embedded soft ware oft en requires a variet y of development t ools, including programming
languages such as C++, Rust , or Pyt hon, and frameworks like Qt for graphical int erfaces. These
t ools enable developers t o creat e efficient , scalable, and feat ure-rich applicat ions t ailored t o t he
specific requirement s of embedded syst ems. The choice of t ools is driven by fact ors such as
real-t ime performance, int egrat ion wit h hardware, or energy efficiency.

As t he complexit y of embedded syst ems grows, higher-level t ools and operat ing syst ems are
migrat ing int o machinery where it makes sense. For example, cellphones, personal digit al
assist ant s and ot her consumer comput ers oft en need significant soft ware t hat is purchased or
provided by a person ot her t han t he manufact urer of t he elect ronics. In t hese syst ems, an open
programming environment such as Linux, Net BSD, FreeBSD, OSGi or Embedded Java is required so
t hat t he t hird-part y soft ware provider can sell t o a large market .

Debugging

Embedded debugging may be performed at different levels, depending on t he facilit ies available.
Considerat ions include: does it slow down t he main applicat ion, how close is t he debugged
syst em or applicat ion t o t he act ual syst em or applicat ion, how expressive are t he t riggers t hat
can be set for debugging (e.g., inspect ing t he memory when a part icular program count er value is
reached), and what can be inspect ed in t he debugging process (such as, only memory, or memory
and regist ers, et c.).

From simplest t o most sophist icat ed debugging t echniques and syst ems are roughly grouped
int o t he following areas:

Int eract ive resident debugging, using t he simple shell provided by t he embedded operat ing
syst em (e.g. Fort h and Basic)

Soft ware-only debuggers have t he benefit t hat t hey do not need any hardware modificat ion
but have t o carefully cont rol what t hey record in order t o conserve t ime and st orage space.[10]

Ext ernal debugging using logging or serial port out put t o t race operat ion using eit her a monit or
in flash or using a debug server like t he Remedy Debugger t hat even works for het erogeneous
mult icore syst ems.

An in-circuit debugger (ICD), a hardware device t hat connect s t o t he microprocessor via a

JTAG or Nexus int erface.[11] This allows t he operat ion of t he microprocessor t o be cont rolled
ext ernally, but is t ypically rest rict ed t o specific debugging capabilit ies in t he processor.
 An in-circuit emulat or (ICE) replaces t he microprocessor wit h a simulat ed equivalent , providing
full cont rol over all aspect s of t he microprocessor.

A complet e emulat or provides a simulat ion of all aspect s of t he hardware, allowing all of it t o
be cont rolled and modified, and allowing debugging on a normal PC. The downsides are
expense and slow operat ion, in some cases up t o 100 t imes slower t han t he final syst em.

For SoC designs, t he t ypical approach is t o verify and debug t he design on an FPGA prot ot ype
board. Tools such as Cert us[12] are used t o insert probes in t he FPGA implement at ion t hat
make signals available for observat ion. This is used t o debug hardware, firmware and soft ware
int eract ions across mult iple FPGAs in an implement at ion wit h capabilit ies similar t o a logic
analyzer.

Unless rest rict ed t o ext ernal debugging, t he programmer can t ypically load and run soft ware
t hrough t he t ools, view t he code running in t he processor, and st art or st op it s operat ion. The
view of t he code may be as high-level programming language, assembly code or mixt ure of bot h.

Tracing

Real-t ime operat ing syst ems oft en support t racing of operat ing syst em event s. A graphical view
is present ed by a host PC t ool, based on a recording of t he syst em behavior. The t race recording
can be performed in soft ware, by t he RTOS, or by special t racing hardware. RTOS t racing allows
developers t o underst and t iming and performance issues of t he soft ware syst em and gives a
good underst anding of t he high-level syst em behaviors. Trace recording in embedded syst ems
can be achieved using hardware or soft ware solut ions. Soft ware-based t race recording does not
require specialized debugging hardware and can be used t o record t races in deployed devices,
but it can have an impact on CPU and RAM usage.[13] One example of a soft ware-based t racing
met hod used in RTOS environment s is t he use of empt y macros which are invoked by t he
operat ing syst em at st rat egic places in t he code, and can be implement ed t o serve as hooks.

Reliability

Embedded syst ems oft en reside in machines t hat are expect ed t o run cont inuously for years
wit hout error, and in some cases recover by t hemselves if an error occurs. Therefore, t he
soft ware is usually developed and t est ed more carefully t han t hat for personal comput ers, and
unreliable mechanical moving part s such as disk drives, swit ches or but t ons are avoided.

Specific reliabilit y issues may include:

The syst em cannot safely be shut down for repair, or it is t oo inaccessible t o repair. Examples
include space syst ems, undersea cables, navigat ional beacons, bore-hole syst ems, and
 aut omobiles.

The syst em must be kept running for safet y reasons. Reduced funct ionalit y in t he event of
failure may be int olerable. Oft en backups are select ed by an operat or. Examples include
aircraft navigat ion, react or cont rol syst ems, safet y-crit ical chemical fact ory cont rols, t rain
signals.

The syst em will lose large amount s of money when shut down: Telephone swit ches, fact ory
cont rols, bridge and elevat or cont rols, funds t ransfer and market making, aut omat ed sales and
service.

A variet y of t echniques are used, somet imes in combinat ion, t o recover from errors—bot h
soft ware bugs such as memory leaks, and also soft errors in t he hardware:

wat chdog t imer t hat reset s and rest art s t he syst em unless t he soft ware periodically not ifies
t he wat chdog subsyst ems

Designing wit h a t rust ed comput ing base (TCB) archit ect ure ensures a highly secure and
reliable syst em environment [14]

A hypervisor designed for embedded syst ems is able t o provide secure encapsulat ion for any
subsyst em component so t hat a compromised soft ware component cannot int erfere wit h
ot her subsyst ems, or privileged-level syst em soft ware.[15] This encapsulat ion keeps fault s
from propagat ing from one subsyst em t o anot her, t hereby improving reliabilit y. This may also
allow a subsyst em t o be aut omat ically shut down and rest art ed on fault det ect ion.

Immunit y-aware programming can help engineers produce more reliable embedded syst ems
code.[16][17] Guidelines and coding rules such as MISRA C/C++ aim t o assist developers
produce reliable, port able firmware in a number of different ways: t ypically by advising or
mandat ing against coding pract ices which may lead t o run-t ime errors (memory leaks, invalid
point er uses), use of run-t ime checks and except ion handling (range/sanit y checks, divide-by-
zero and buffer index validit y checks, default cases in logic checks), loop bounding, product ion
of human-readable, well comment ed and well st ruct ured code, and avoiding language
ambiguit ies which may lead t o compiler-induced inconsist encies or side-effect s (expression
evaluat ion ordering, recursion, cert ain t ypes of macro). These rules can oft en be used in
conjunct ion wit h code st at ic checkers or bounded model checking for funct ional verificat ion
purposes, and also assist in det erminat ion of code t iming propert ies.[16]

High vs. low volume

For high-volume syst ems such as mobile phones, minimizing cost is usually t he primary design
considerat ion. Engineers t ypically select hardware t hat is just good enough t o implement t he
necessary funct ions.
For low-volume or prot ot ype embedded syst ems, general-purpose comput ers may be adapt ed
by limit ing t he programs or by replacing t he operat ing syst em wit h an RTOS.

Embedded software architectures

In 1978 Nat ional Elect rical Manufact urers Associat ion released ICS 3-1978, a st andard for
programmable microcont rollers,[18] including almost any comput er-based cont rollers, such as
single-board comput ers, numerical, and event -based cont rollers.

There are several different t ypes of soft ware archit ect ure in common use.

Simple control loop

In t his design, t he soft ware simply has a loop which monit ors t he input devices. The loop calls
subrout ines, each of which manages a part of t he hardware or soft ware. Hence it is called a
simple cont rol loop or programmed input -out put .

Interrupt-controlled system

Some embedded syst ems are predominant ly cont rolled by int errupt s. This means t hat t asks
performed by t he syst em are t riggered by different kinds of event s; an int errupt could be
generat ed, for example, by a t imer at a predefined int erval, or by a serial port cont roller receiving
dat a.

This archit ect ure is used if event handlers need low lat ency, and t he event handlers are short and
simple. These syst ems run a simple t ask in a main loop also, but t his t ask is not very sensit ive t o
unexpect ed delays. Somet imes t he int errupt handler will add longer t asks t o a queue st ruct ure.
Lat er, aft er t he int errupt handler has finished, t hese t asks are execut ed by t he main loop. This
met hod brings t he syst em close t o a mult it asking kernel wit h discret e processes.

Cooperative multitasking

Cooperat ive mult it asking is very similar t o t he simple cont rol loop scheme, except t hat t he loop
is hidden in an API.[3][1] The programmer defines a series of t asks, and each t ask get s it s own
environment t o run in. When a t ask is idle, it calls an idle rout ine which passes cont rol t o anot her
t ask.

The advant ages and disadvant ages are similar t o t hat of t he cont rol loop, except t hat adding
new soft ware is easier, by simply writ ing a new t ask, or adding t o t he queue.
Preemptive multitasking or multi-threading

In t his t ype of syst em, a low-level piece of code swit ches bet ween t asks or t hreads based on a
t imer invoking an int errupt . This is t he level at which t he syst em is generally considered t o have
an operat ing syst em kernel. Depending on how much funct ionalit y is required, it int roduces more
or less of t he complexit ies of managing mult iple t asks running concept ually in parallel.

As any code can pot ent ially damage t he dat a of anot her t ask (except in syst ems using a memory
management unit ) programs must be carefully designed and t est ed, and access t o shared dat a
must be cont rolled by some synchronizat ion st rat egy such as message queues, semaphores or a
non-blocking synchronizat ion scheme.

Because of t hese complexit ies, it is common for organizat ions t o use an off-t he-shelf RTOS,
allowing t he applicat ion programmers t o concent rat e on device funct ionalit y rat her t han
operat ing syst em services. The choice t o include an RTOS brings in it s own issues, however, as
t he select ion must be made prior t o st art ing t he applicat ion development process. This t iming
forces developers t o choose t he embedded operat ing syst em for t heir device based on current
requirement s and so rest rict s fut ure opt ions t o a large ext ent .[19]

The level of complexit y in embedded syst ems is cont inuously growing as devices are required t o
manage peripherals and t asks such as serial, USB, TCP/IP, Bluet oot h, Wireless LAN, t runk radio,
mult iple channels, dat a and voice, enhanced graphics, mult iple st at es, mult iple t hreads, numerous
wait st at es and so on. These t rends are leading t o t he upt ake of embedded middleware in
addit ion t o an RTOS.

Microkernels and exokernels

A microkernel allocat es memory and swit ches t he CPU t o different t hreads of execut ion. User-
mode processes implement major funct ions such as file syst ems, net work int erfaces, et c.

Exokernels communicat e efficient ly by normal subrout ine calls. The hardware and all t he soft ware
in t he syst em are available t o and ext ensible by applicat ion programmers.

Monolithic kernels

A monolit hic kernel is a relat ively large kernel wit h sophist icat ed capabilit ies adapt ed t o suit an
embedded environment . This gives programmers an environment similar t o a deskt op operat ing
syst em like Linux or Microsoft Windows, and is t herefore very product ive for development . On
t he downside, it requires considerably more hardware resources, is oft en more expensive, and,
because of t he complexit y of t hese kernels, can be less predict able and reliable.
Common examples of embedded monolit hic kernels are embedded Linux, VXWorks and Windows
CE.

Despit e t he increased cost in hardware, t his t ype of embedded syst em is increasing in popularit y,
especially on t he more powerful embedded devices such as wireless rout ers and GPS navigat ion
syst ems.

Additional software components

In addit ion t o t he core operat ing syst em, many embedded syst ems have addit ional upper-layer
soft ware component s. These component s include net working prot ocol st acks like CAN, TCP/IP,
FTP, HTTP, and HTTPS, and st orage capabilit ies like FAT and flash memory management
syst ems. If t he embedded device has audio and video capabilit ies, t hen t he appropriat e drivers
and codecs will be present in t he syst em. In t he case of t he monolit hic kernels, many of t hese
soft ware layers may be included in t he kernel. In t he RTOS cat egory, t he availabilit y of addit ional
soft ware component s depends upon t he commercial offering.

Domain-specific architectures

In t he aut omot ive sect or, AUTOSAR is a st andard archit ect ure for embedded soft ware.

See also

Electronics portal

Communicat ions server

Cyber-physical syst em

Elect ronic cont rol unit

Informat ion appliance

Int egrat ed development environment

Phot onically Opt imized Embedded Microprocessors

Silicon compiler

Soft ware engineering

Syst em on module

Ubiquit ous comput ing

Notes

1. For more det ails of MicroVGA see t his PDF (ht t p://www.microvga.com/pdf/uvga-t ext -ds.pd
f) .

References

1. Michael Barr. "Embedded Syst ems Glossary" (ht t p://www.net rino.com/Embedded-Syst ems/
Glossary) . Neutrino Technical Library. Ret rieved 2007-04-21.

2. Heat h, St eve (2003). Embedded systems design (ht t ps://archive.org/det ails/embeddedsyst

emsd0000heat ) . EDN series for design engineers (2 ed.). Newnes. p. 2 (ht t ps://archive.org/
det ails/embeddedsyst emsd0000heat /page/2) . ISBN 978-0-7506-5546-0. "An embedded
syst em is a microprocessor based syst em t hat is built t o cont rol a funct ion or a range of
funct ions."

3. Michael Barr; Ant hony J. Massa (2006). "Int roduct ion" (ht t ps://books.google.com/books?id=n
PZaPJrw_ L0C&pg=PA1) . Programming embedded systems: with C and GNU development
tools . O'Reilly. pp. 1–2. ISBN 978-0-596-00983-0.

4. Barr, Michael (1 August 2009). "Real men program in C" (ht t ps://www.embedded.com/elect ro
nics-blogs/barr-code/4027479/Real-men-program-in-C) . Embedded Systems Design.
TechInsight s (Unit ed Business Media). p. 2. Ret rieved 2009-12-23.

5. Shirriff, Ken (30 August 2016). "The Surprising St ory of t he First Microprocessors" (ht t ps://s
pect rum.ieee.org/t he-surprising-st ory-of-t he-first -microprocessors) . IEEE Spectrum. 53
(9). Inst it ut e of Elect rical and Elect ronics Engineers: 48–54.
doi:10.1109/MSPEC.2016.7551353 (ht t ps://doi.org/10.1109%2FMSPEC.2016.7551353) .
S2CID 32003640 (ht t ps://api.semant icscholar.org/CorpusID:32003640) . Ret rieved
13 Oct ober 2019.

6. "1971: Microprocessor Int egrat es CPU Funct ion ont o a Single Chip" (ht t ps://www.comput erh
ist ory.org/siliconengine/microprocessor-int egrat es-cpu-funct ion-ont o-a-single-chip/) . The
Silicon Engine. Comput er Hist ory Museum. Ret rieved 22 July 2019.

7. "Elect ronic Front ier Foundat ion" (ht t ps://www.eff.org/) . Electronic Frontier Foundation.

8. Embedded Syst ems Dell OEM Solut ions | Dell (ht t p://cont ent .dell.com/us/en/ent erprise/oe
m-indust ry-solut ions-build-your-product -wit h-dell) Archived (ht t ps://web.archive.org/web/
20130127080734/ht t p://cont ent .dell.com/us/en/ent erprise/oem-indust ry-solut ions-build-y
our-product -wit h-dell) 2013-01-27 at t he Wayback Machine. Cont ent .dell.com (2011-01-
04). Ret rieved on 2013-02-06.
 9. David Carey (2008-04-22). "Under t he Hood: Robot Guit ar embeds aut ot uning" (ht t ps://web.a
rchive.org/web/20080708195311/ht t p://embedded.com/undert hehood/207401418) .
Embedded Systems Design . Archived from t he original (ht t ps://www.embedded.com/undert h
ehood/207401418) on 2008-07-08.

10. Tancret i, Mat t hew; Sundaram, Vinait heert han; Bagchi, Saurabh; Eugst er, Pat rick (2015).
"TARDIS". Proceedings of the 14th International Conference on Information Processing in
Sensor Networks . IPSN '15. New York, NY, USA: ACM. pp. 286–297.
doi:10.1145/2737095.2737096 (ht t ps://doi.org/10.1145%2F2737095.2737096) .
ISBN 9781450334754. S2CID 10120929 (ht t ps://api.semant icscholar.org/CorpusID:1012092
9) .

11. Tancret i, Mat t hew; Hossain, Mohammad Sajjad; Bagchi, Saurabh; Raghunat han, Vijay (2011).
"Aveksha". Proceedings of the 9th ACM Conference on Embedded Networked Sensor
Systems . SenSys '11. New York, NY, USA: ACM. pp. 288–301. doi:10.1145/2070942.2070972
(ht t ps://doi.org/10.1145%2F2070942.2070972) . ISBN 9781450307185. S2CID 14769602
(ht t ps://api.semant icscholar.org/CorpusID:14769602) .

12. Morris, Kevin (2012-10-30). "Tekt ronix Shakes Up Prot ot yping, Embedded Inst rument at ion
Boost s Boards t o Emulat or St at us" (ht t p://www.eejournal.com/archives/art icles/20121030-
t ekt ronix/) . Elect ronic Engineering Journal. Ret rieved 2012-10-30.

13. Kraft , Johan; Wall, Anders; Kienle, Holger (2010), Barringer, Howard; Falcone, Ylies; Finkbeiner,
Bernd; Havelund, Klaus (eds.), "Trace Recording for Embedded Syst ems: Lessons Learned
from Five Indust rial Project s" (ht t p://link.springer.com/10.1007/978-3-642-16612-9_ 24) ,
Runtime Verification , vol. 6418, Berlin, Heidelberg: Springer Berlin Heidelberg, pp. 315–329,
doi:10.1007/978-3-642-16612-9_ 24 (ht t ps://doi.org/10.1007%2F978-3-642-16612-9_ 24) ,
ISBN 978-3-642-16611-2, ret rieved 2022-08-16

14. Heiser, Gernot (December 2007). "Your Syst em is secure? Prove it !" (ht t p://c59951.r51.cf2.r
ackcdn.com/5557-528-heiser.pdf) (PDF). ;login: . 2 (6): 35–8. Archived (ht t ps://web.archive.
org/web/20141129070740/ht t p://c59951.r51.cf2.rackcdn.com/5557-528-heiser.pdf)
(PDF) from t he original on 2014-11-29.

15. Morat elli, C; Johann, S; Neves, M; Hessel, F (2016). "Embedded virt ualizat ion for t he design
of secure IoT applicat ions" (ht t ps://ieeexplore.ieee.org/document /7909116) . Proceedings
of the 27th International Symposium on Rapid System Prototyping: Shortening the Path from
Specification to Prototype. pp. 2–6. doi:10.1145/2990299.2990301 (ht t ps://doi.org/10.114
5%2F2990299.2990301) . ISBN 9781450345354. S2CID 17466572 (ht t ps://api.semant icsc
holar.org/CorpusID:17466572) . Ret rieved 2 February 2018.
16. Short , Michael (March 2008). "Development guidelines for dependable real-t ime embedded
syst ems" (ht t ps://ieeexplore.ieee.org/document /4493674) . 2008 IEEE/ACS International
Conference on Computer Systems and Applications (ht t ps://figshare.com/art icles/conferen
ce_ cont ribut ion/Development _ Guidelines_ for_ Dependable_ Real-Time_ Embedded_ Syst em
s_ /10083272) . pp. 1032–1039. doi:10.1109/AICCSA.2008.4493674 (ht t ps://doi.org/10.110
9%2FAICCSA.2008.4493674) . ISBN 978-1-4244-1967-8. S2CID 14163138 (ht t ps://api.sem
ant icscholar.org/CorpusID:14163138) .

17. Mot or Indust ry Soft ware Reliabilit y Associat ion. "MISRA C:2012 Third Edit ion, First Revision"
(ht t ps://www.misra.org.uk/product /misra-c2012-t hird-edit ion-first -revision/) . Ret rieved
2022-02-03.

18. "FAQs: Programmable Cont rollers" (ht t ps://www.nema.org/docs/default -source/st andards-d

ocument -library/faq-programmable-cont rollers.pdf?sfvrsn=a03312d_ 2) (PDF). Ret rieved
2020-01-10.

19. "Working across Mult iple Embedded Plat forms" (ht t p://www.clarinox.com/docs/whit epaper
s/Whit epaper_ 06_ CrossPlat formDiscussion.pdf) (PDF). clarinox. Archived (ht t ps://web.arc
hive.org/web/20110219200027/ht t p://www.clarinox.com/docs/whit epapers/Whit epaper_ 0
6_ CrossPlat formDiscussion.pdf) (PDF) from t he original on 2011-02-19. Ret rieved
2010-08-17.

Further reading

John Cat soulis (May 2005). Designing Embedded Hardware, 2nd Edition. O'Reilly. ISBN 0-596-
00755-8.

James M. Conrad; Alexander G. Dean (Sept ember 2011). Embedded Systems, An Introduction
Using the Renesas RX62N Microcontroller. Micrium. ISBN 978-1935-7729-96.

Klaus Elk (August 2016). Embedded Software Development for the Internet Of Things, The
Basics, The Technologies and Best Practices . Creat eSpace Independent Publishing Plat form.
ISBN 978-1534602533.

External links

Embedded Syst ems course wit h mbed (ht t ps://www.yout ube.com/wat ch?v=H-OKGOMoCSI&li
st =PLo7bVbJhQ6qwlDa-R6pz7t A7kPzn1s5Ae) YouTube, ongoing from 2015

Trends in Cyber Securit y and Embedded Syst ems (ht t p://geer.t inho.net /geer.nro.6xi13.t xt )
Dan Geer, November 2013

Modern Embedded Syst ems Programming Video Course (ht t ps://www.yout ube.com/playlist ?lis
t =PLPW8O6W-1chwyTzI3BHwBLbGQoPFxPAPM) YouTube, ongoing from 2013
Embedded Syst ems Week (ESWEEK) (ht t p://www.esweek.org/) yearly event wit h
conferences, workshops and t ut orials covering all aspect s of embedded syst ems and
soft ware

Workshop on Embedded and Cyber-Physical Syst ems Educat ion (ht t ps://web.archive.org/web/
20180211173413/ht t p://www.emsig.net /conf/2015/wese/) at t he Wayback Machine
(archived 2018-02-11), workshop covering educat ional aspect s of embedded syst ems

Developing Embedded Syst ems - A Tools Int roduct ion (ht t ps://microcont rollershop.com/An%2
0Embedded%20Tools%20Int roduct ion.php)