Embedded system

An embedded system is a computer system designed to perform one or a few dedicated functions, often with real-time computing constraints.Embedded systems are controlled by a main processing core that is typically either a microcontroller or a digital signal processor (DSP). Since the embedded system is dedicated to specific tasks, design engineers can optimize it, reducing the size and cost of the product, or increasing the reliability and performance. Some embedded systems are mass-produced, benefiting from economies of scale.

Physically, embedded systems range from portable devices such as digital watches and MP3 players, to large stationary installations like traffic lights, factory controllers, or the systems controlling nuclear power plants. Complexity varies from low, with a single microcontroller chip, to very high with multiple units, peripherals and networks mounted inside a large chassis or enclosure.

In general, "embedded system" is not an exactly defined term, as many systems have some element of programmability. For example, Handheld computers share some elements with embedded systems such as the operating systems and microprocessors which power them but are not truly embedded systems, because they allow different applications to be loaded and peripherals to be connected.

Characteristics

Embedded systems are designed to do some specific task, rather than be a general-purpose computer for multiple tasks. Some also have real-time performance constraints that must be met, for reasons such as safety and usability; others may have low or no performance requirements, allowing the system hardware to be simplified to reduce costs.

Embedded systems are not always standalone devices. Many embedded systems consist of small, computerized parts within a larger device that serves a more general purpose. For example, the Gibson Robot Guitar features an embedded system for tuning the strings, but the overall purpose of the Robot Guitar is, of course, to play music.Similarly, an embedded system in an automobile provides a specific function as a subsystem of the car itself.

The program instructions written for embedded systems are referred to as firmware, and are stored in read-only memory or Flash memory chips. They run with limited computer hardware resources: little memory, small or non-existent keyboard and/or screen.

Reliability

Embedded systems often reside in machines that are expected to run continuously for years without errors, and in some cases recover by themselves if an error occurs. Therefore the software is usually developed and tested more carefully than that for personal computers, and unreliable mechanical moving parts such as disk drives, switches or buttons are avoided.

Specific reliability issues may include:

• The system cannot safely be shut down for repair, or it is too inaccessible to repair. Examples include space systems, undersea cables, navigational beacons, bore-hole systems, and automobiles.
• The system must be kept running for safety reasons. "Limp modes" are less tolerable. Often backups are selected by an operator. Examples include aircraft navigation, reactor control systems, safety-critical chemical factory controls, train signals, engines on single-engine aircraft.
• The system will lose large amounts of money when shut down: Telephone switches, factory controls, bridge and elevator controls, funds transfer and market making, automated sales and service.

A variety of techniques are used, sometimes in combination, to recover from errors both software bugs such as memory leaks, and also soft errors in the hardware:

• watchdog timer that resets the computer unless the software periodically notifies the watchdog
• subsystems with redundant spares that can be switched over to
• software "limp modes" that provide partial function
• Designing with a Trusted Computing Base (TCB) architecture ensures a highly secure & reliable system environment
• An Embedded Hypervisor is able to provide secure encapsulation for any subsystem component, so that a compromised software component cannot interfere with other subsystems, or privileged-level system software. This encapsulation keeps faults from propagating from one subsystem to another, improving reliability. This may also allow a subsystem to be automatically shut down and restarted on fault detection.
• Immunity Aware Programming

Categories

1. Stand alone
2. Real-time
3. Networked information appliances
4. Mobile

Stand alone

• Examples – digital camera, microwave oven, mp3 player
• Works alone – unlike the mobile phone…  
• Uses a processor, has memory, and runs under program control. But, these are of no concern to user…
• To him, it is a dum, silly device, doing a specific job

Real time

• One of the most misused words…
• Hard and soft…  
• Meeting of dead-line….
• Catastrophe
• Relates to servicing of hardware interrupts…
• Interrupt servicing introduces interrupt latency
• Realtime systems are those in which developer can have detailed control on interrupt latency

Networked information appliances

• Recent
• Example – web camara…  
• System has an ip and can be controlled from anywhere in the web…
• Has tcp/ip protocol plus application layer software
• Might dominate the scene in future

Mobile devices

• Mobile phones…
• Pda  
• Smart phones…
• Mobile phones will slowly grow in capability to include functionality of lap-tops…
• What will laptops do ?

Overview of embedded system architecture

Topmost view

1. Hardware
2. Operating system
3. Application software  

Hardware

• CPU
• Random access memory
• Read only memory
• Input devices
• Output devices
• Communication interfaces
• User developed circuitry

Specialities

• Reliability
• Performance
• Power consumption
• Cost
• Size
• Limited user interface
• Upgradation

Trends

• Increased processor power
• More memory
• Specialised operating systems
• Networking
• More compilers
• Many development tools
• Programmable hardware

Peripherals

• Embedded Systems talk with the outside world via peripherals, such as:
• Serial Communication Interfaces (SCI): RS-232, RS-422, RS-485 etc
• Synchronous Serial Communication Interface: I2C, SPI, SSC and ESSI (Enhanced Synchronous Serial Interface)
• Universal Serial Bus (USB)
• Multi Media Cards (SD Cards, Compact Flash etc)
• Networks: Ethernet, Controller Area Network, LonWorks, etc
• Timers: PLL(s), Capture/Compare and Time Processing Units
• Discrete IO: aka General Purpose Input/Output (GPIO)
• Analog to Digital/Digital to Analog (ADC/DAC)
• Debugging: JTAG, ISP, ICSP, BDM Port, ...

Interrupts

Basics

• Starts from hardware
• IRQ gets asserted
• Processor goes to interrupt routine (ISR)
• After saving the context
• On iret, it restores context and continues with where it left
• Linkage to ISR is through an interrupt vector table
• Interrupts are usually disabled within an ISR

Context saving

• Saving is to stack
• All registers that you use
• Should be restored before exit
• Can be time consuming
• Will increase interrupt latency
• Failing to save is catastrophic
• Have an eye on stack depth

Disabling interrupts

• On entry in an isr, interrupts are normally disabled…
• Specifically enable them, in case you need this
• Remember that this can lead to obscure bugs
• Safe option is to keep isr very small so that disabling interrupts during this time is acceptable

Writing ISR

• Can be in assembler or c
• In prototype stage, write in c 
• Once things starts working and you are close to integration, convert to assembler
• Keep it small and straight
• Analyse thoroughly

Shared data problem

• When the main routine and isr share a memory area, the isr may modify a portion of the memory that was under usage by main routine
• When interrupt returns, the main routine continues execution, without being aware that, memory is updated by ISR
• This can lead to a serious bug….

Critical section

• Area of code that cannot be interrupted
• Enclosing the section with disable…..enable brackets can do the trick  
• Do not do this in a general subroutine that could be called from many other routines… (why not ?)
• Be aware that this compromises the system performance…

Latency

• Most important factor for system performance analysis
• For the highest priority interrupt this is equal to context switching time plus largest interrupt disabled period  
• For other interrupts the analysis is more complex
• You have to consider the frequency of higher priority interrupts, and the time taken by their isrs
• Understand your hardware very well before you sit down to analyse the latency…

Thumb rules

• Make isr as small and simple as possible
• Analyse latency problem very carefully before you start debugging the code
• Disable interrupts only if you must
• However, be aware that in a large number of situations, it is the simplest way out…  

Software architectures

1. Round robin
2. Round robin with interrupts
3. Function queue scheduling
4. Rtos

Round robin

• Contains a single main loop that polls each device one after the other and service them
• Simplest
• No interrupts
• No shared data problem
• No latency concern
• Problem:- frequency of interrupt cannot be higher than reciprocal of the total polling loop time

Round robin with interrpts

• A number of isrs that performs minimal interrupt servicing and set up a flag for followup servicing
• Main loop polls the flags for for follw up service
• Shared data problem exist….
• Problem:- all task codes in the main round robin loop executes with same priority

Function queue scheduling

• A number of isrs that performs minimal interrupt servicing and add a pointer to followup function into a function queue
• Main loop goes through this queue and executes them
• A priority scheme for execution of calls in the queue may be implemented..

RTOS

• Purchased off the shelf
• Splits total system to kernal and user tasks
• Kernal consists of isr and scheduler 
• The application code is organised as tasks
• Concurrent running of all task codes 
• PROS
• Development will be more deciplined and streamlined
• Easy to upgrade
• Stable performance
• Complexity is handled by someone else
• CONS
• Price
• Higher overheads
• More complex and hence bigger learning curve

Selecting an architecture

• Take the simplest
• That meets your requirements 
• Remember possible future requirements also
• Keep it small and straight
• And expandable
• It is a tricky decision…

Embedded system development tools

• Host and target
• Linker locator
• Getting system to target
• Debugging
• Testing on host
• Instruction set simulators
• Assert macro
• Using laboratory tools

Host & target

Host : the system used for development

Target : the actual system in which the developed software will run 

Native : a software tools (eg. Compiler) that generate code meant for the processor on which it runs.

Cross : a software tools (eg. Compiler) that generate code meant for another processor than the processor on which it runs.

Strategy

1. Develop proto-system on host
2. Test proto-system on host
3. Ok ?
4. Cross compile for target
5. Download to target
6. Test on target
7. Ok ?
8. Release

Developing proto system on host

• Purpose 
• Test out concept
• And mmi
• And general working
• And task structures
• But not exact system or timing details
• Method:
• Use actual components whereever possible
• And stubs, in all other cases
• Test out system as extensively as possible

Tool chain for development for host 

Tool chain for development for target 

Cross compilation issues

• Expect compilation errors
• Number of bytes for basic types may be different;
• Packing could be different;
• Word-alignment rules could be different;
• Support routines could be different;
• Be prepared for surprises and a lot of it 

Linker/Locator

• Native linker creates an executable module that has call to os services
• Cross-linker / locator creates a complete memory image including the rtos modules that you link  
• Native os loads the executable created
• There is no uniform method for loading the memory image created by locator

Intel hex file format

• A common format in which locators create the memory image
• Is a standard ascii text file
• Each line starts with colon(:)
• Followed by 2 digit count
• Followed by 4/8 digit address
• Followed by type
• Followed by stream of data, each two digit – for a byte
• Followed by 2 digit checksum
• CLICK HERE FOR MORE

Memory issues 

• Part of code to go to rom another part to ram
• Ram has many segments like code / data/ stack/extra…
• Address need not be contigeous
• On-chip ram/rom is normally much faster than off-chip memory
• Executing from eprom is slower than that from ram
• All these issues are to be considered by locator

Segmentation 

• Translation tool gives provision for specifying different segments to code generated
• Code within a segment is allocated contigeously
• During load time, we can specify start address of each segment
• Cross compilers give pre-defined names to segments, but you have to specify this in assemblers
• Examples are .code, .data, etc.

Initialisation 

• C assumes that prior to execution the variables are filled with given values
• A constant segment is created to take care of this
• It contains the defined constants, string values, etc., used in the program.
• The loader should ensure that the variables are properly initialised with these

Gathering of segments 

Locator maps 

• Lists where in memory the locator placed the segments
• Gives the location of global variables and routines as well
• Very valuable for debugging
• Check this to ensure that the memory allocations are in fact right…

Executing from ram 

• In systems having ram and rom, it is a good practce to place code in rom and data in ram
• But, in many cases ram is faster
• You may have to move rom contents to ram before execution
• In this case it makes sense to keep code in a compressed format
• An initialisation code then transfers it to ram before execution

Getting to target hardware 

• Prom programmer
• Flash
• Rom emulator
• Monitors
• Incircuit emulators
• Communication devices