UNIT 4 - EMBEDDED SOFTWARE DEVELOPMENT PROCESS

Meeting real time constraints – Multistate systems and function sequences. Embedded software
development tools – Emulators and debuggers. Design methodologies

Introduction
A multistate system in embedded systems refers to a design architecture where the system
operates in multiple distinct states, each with its own behavior, and transitions between these states based
on inputs, time, or both.

Two broad categories of multi-state systems: I. Multi-State (Timed) and II. Multi-State (Input / Timed)

I. Multi-State (Timed)
In a multi-state (timed) system, the transition between states will depend only on the passage of
time.
For example, the system might begin in State A, repeatedly executing Function A, for ten
seconds. It might then move into State B and remain there for 5 seconds, repeatedly executing Function
B. It might then move back into State A, ad infinituum. A basic traffic-light control system might follow this
pattern.
Implementing a Multi-State (Timed) system
It can describe the time-driven, multi-state architecture as follows:
 The system will operate in two or more states.
 Each state may be associated with one or more function calls.
 Transitions between states will be controlled by the passage of time.
 Transitions between states may also involve function calls.

Please note that, in order to ease subsequent maintenance tasks, the system states should not be
arbitrarily named, but should - where possible - reflect a physical state observable by the user and /
or developer. Please also note that the system states will usually be represented by means of a
switch statement in the operating system ISR

Example: Traffic light sequencing - . Multi-State (Timed)

Here is a simple example of a traffic light control program written in Keil C for an 8051 microcontroller. This
program simulates a basic traffic light system with Red, Yellow, and Green LEDs connected to specific pins
of the microcontroller.
#include <reg51.h> // Include header file for 8051 microcontroller

// Define pins for LEDs

sbit RED = P2^0; // Red LED connected to P2.0
sbit YELLOW = P2^1; // Yellow LED connected to P2.1
sbit GREEN = P2^2; // Green LED connected to P2.2

void delay(unsigned int time)

{
 unsigned int i, j;
for (i = 0; i < time; i++)
{
for (j = 0; j < 1275; j++); // Approximate delay
}
}

void main()
{
while (1)
{
// Turn on Red LED
RED = 1;
YELLOW = 0;
GREEN = 0;
delay(500); // Delay for Red light (e.g., 5 seconds)

// Turn on Yellow LED

RED = 0;
YELLOW = 1;
GREEN = 0;
delay(200); // Delay for Yellow light (e.g., 2 seconds)

// Turn on Green LED

RED = 0;
YELLOW = 0;
GREEN = 1;
delay(500); // Delay for Green light (e.g., 5 seconds)
}
}
Explanation:
1. LED Connections: The Red, Yellow, and Green LEDs are connected to pins P2.0, P2.1, and P2.2
of Port 2, respectively.
2. Delay Function: A simple delay function is used to create time intervals for each light.
3. Logic: The program continuously cycles through Red, Yellow, and Green lights with appropriate
delays.

II. Multi-State (Input / Timed)

This is a more common form of system, in which the transition between states (and behaviour in
each state) will depend both on the passage of time and on system inputs.
For example, the system might only move between State A and State B if a particular input is
received within X seconds of a system output being generated. Example : The autopilot system, washing
machine, or an intruder alarm system.
 Another type is Multi-State (Input) - This is a comparatively rare form of system, in which the
transition between states (and behaviour in each state) depends only on the system inputs. For example,
the system might only move between State A and State B if a particular input is received. It will remain
indefinitely in State A if this input is not received. Such systems have no concept of time, and - therefore -
no way of implementing timeout or similar behaviours.

Implementing a Multi-State (Input/Timed) system

The system will operate in two or more states.
 Each state may be associated with one or more function calls.
 Transitions between states may be controlled by the passage of time, by system inputs or
a combination of time and inputs.
 Transitions between states may also involve function calls

Example: Controller for a washing machine - Multi-State (Input/Timed) system

Here is a brief description of the way in which we expect the system to operate:
1. The user selects a wash program (e.g. ‗Wool‘, ‗Cotton‘) on the selector dial.
2. The user presses the ‗Start‘ switch.
3. The door lock is engaged.
4. The water valve is opened to allow water into the wash drum.
5. If the wash program involves detergent, the detergent hatch is opened. When the detergent has
been released, the detergent hatch is closed.
6. When the ‗full water level‘ is sensed, the water valve is closed.
7. If the wash program involves warm water, the water heater is switched on. When the water
reaches the correct temperature, the water heater is switched off.
8. The washer motor is turned on to rotate the drum. The motor then goes through a series of
movements, both forward and reverse (at various speeds) to wash the clothes. (The precise set of
movements carried out depends on the wash program that the user has selected.) At the end of
the wash cycle, the motor is stopped.
9. The pump is switched on to drain the drum. When the drum is empty, the pump is switched off
Keil C Program :
#include <reg51.h> // Assuming 8051 microcontroller
// Define control pins
sbit START_SWITCH = P1^0;
sbit DOOR_LOCK = P1^1;
sbit WATER_VALVE = P1^2;
sbit DETERGENT_HATCH = P1^3;
sbit WATER_LEVEL_SENSOR = P1^4;
sbit HEATER = P1^5;
sbit TEMP_SENSOR = P1^6;
sbit MOTOR = P1^7;
sbit PUMP = P2^0;

// Wash program selector (e.g., Wool = 0x01, Cotton = 0x02)

unsigned char wash_program;

void delay(unsigned int ms)

{
unsigned int i, j;
for(i = 0; i < ms; i++)
for(j = 0; j < 1275; j++);
}

void lock_door()
{
DOOR_LOCK = 1;
delay(1000);
}

void fill_water()
{
WATER_VALVE = 1;
while(WATER_LEVEL_SENSOR == 0); // Wait until full
WATER_VALVE = 0;
}

void release_detergent()
{
DETERGENT_HATCH = 1;
delay(1000); // Simulate release time
DETERGENT_HATCH = 0;
}

void heat_water()
{
HEATER = 1;
while(TEMP_SENSOR == 0); // Wait until desired temp
HEATER = 0;
}

void motor_cycle(unsigned char program)

{
MOTOR = 1;
if(program == 0x01)
{ // Wool
delay(3000); // Gentle cycle
} else if(program == 0x02)
{ // Cotton
delay(5000); // Intense cycle
}
MOTOR = 0;
}

void drain_water()
{
PUMP = 1;
delay(3000); // Simulate drain time
PUMP = 0;
}

void main()
{
wash_program = 0x02; // Example: Cotton selected

while(1) {
if(START_SWITCH == 1) {
lock_door();
fill_water();

if(wash_program == 0x01 || wash_program == 0x02)

{
release_detergent();
}

if(wash_program == 0x02)
{ // Cotton requires warm water
heat_water();
}
 motor_cycle(wash_program);
drain_water();
}
}
}

Example : Write a keil c program for intruder alarm system using multi state input and time -
Implementing a Multi-State (Input/Timed) system
 Multi-state inputs: Monitors three sensors—door, window, and motion.
 Immediate alarm: Door or window breach triggers alarm instantly.
 Timed alarm: Motion sensor must be active for 5 seconds continuously before triggering.
 Outputs: Alarm buzzer and LED indicator are activated when intrusion is detected.

#include <reg51.h>

// Define input sensors

sbit DOOR_SENSOR = P1^0;
sbit WINDOW_SENSOR = P1^1;
sbit MOTION_SENSOR = P1^2;

// Define output devices

sbit ALARM = P2^0;
sbit LED_INDICATOR = P2^1;

// Timer variables
unsigned int motion_detected_time = 0;
bit motion_timer_active = 0;

void delay_ms(unsigned int ms)

{
unsigned int i, j;
for(i = 0; i < ms; i++)
for(j = 0; j < 1275; j++);
}

void activate_alarm()
{
ALARM = 1;
LED_INDICATOR = 1;
}

void deactivate_alarm()
{
ALARM = 0;
LED_INDICATOR = 0;
}

void check_sensors()
{
// Immediate alarm for door or window breach
if(DOOR_SENSOR == 1 || WINDOW_SENSOR == 1)
{
activate_alarm();
}

// Motion sensor triggers alarm only if motion persists for 5 seconds

if(MOTION_SENSOR == 1)
{
if(!motion_timer_active)
{
motion_timer_active = 1;
motion_detected_time = 0;
} else
{
motion_detected_time++;
if(motion_detected_time >= 5)
{
activate_alarm();
}
}
}
else
{
motion_timer_active = 0;
motion_detected_time = 0;
}
}

void main()
{ // Initialize outputs
deactivate_alarm();
while(1)
{
check_sensors();
delay_ms(1000); // 1-second interval
}}
Development process of an embedded system

Embedded Systems Development Phase Breakdown

This phase involves parallel development of hardware and software, followed by integration and testing.
Here's how each component fits in:

A. Hardware Path
1. Hardware Selection
o Choose the microcontroller, sensors, actuators, and other components based on
application needs (e.g., power, speed, I/O).
o Once selected, these components are typically fixed for the rest of the development cycle.
2. Assembly for Target System
o Physically assemble the hardware: mount components on PCBs, connect interfaces, and
ensure power delivery.
o This is the prototype or development board setup.
3. Test Hardware
o Verify that the hardware functions correctly: power-on tests, signal integrity checks, and
peripheral communication.
o If issues arise, the flow loops back to Reassemble on Hardware Error—this could mean
replacing faulty components or redesigning the PCB.
4. O.K. Decision Point
o If hardware passes all tests, it's approved for integration with software.

B. Software Path
1. Software Development
o This is where the Edit-Test-Debug cycle comes in:
 Edit: Write code (often in C/C++) tailored to the hardware.
  Test: Run the code on the target board or simulator.
 Debug: Use tools like JTAG, serial monitors, or IDE debuggers to fix issues.
o This cycle repeats until the software behaves as expected.
2. Burn Codes using Device Programmer
o Once the software is stable, it's flashed into the microcontroller‘s non-volatile memory
using a programmer.
o This makes the code persistent and ready for deployment.
3. Redesign on Software Errors
o If bugs or performance issues are found during testing, the flow loops back to
development.
o This might involve rewriting code, optimizing memory usage, or adjusting timing
constraints.

Final Integration
Once both hardware and software are verified independently, they‘re integrated and tested as a complete
system. The goal is to ensure:
 Real-time performance
 Power efficiency
 Functional correctness
 Robustness under edge conditions

Edit-Test-Debug Cycle implementation phase of the development process

The Edit-Test-Debug cycle is a critical part of embedded system development. It involves:

 Editing the source code
 Testing the code on hardware or simulated environments
 Debugging to identify and fix errors
Different approaches are used depending on the development stage, hardware availability, and debugging
needs.
1. Using a Target System
 Definition: Code is directly executed on the actual embedded hardware.
 Use Case: Final testing phase; when hardware is available.
 Advantages:
 Real-world accuracy
 True performance and timing behavior
  Limitations:
 Difficult to debug without built-in tools
 Limited visibility into internal states
2. Using an Emulator for Target System
 Definition: A software or hardware emulator mimics the target system‘s behavior.
 Use Case: Early development; when hardware is unavailable.
 Advantages:
 Cost-effective
 Easier to test and iterate
 Limitations:
 May not replicate exact hardware behavior
 Timing and peripheral interactions may differ
3. Using Target Processor and ICE (In-Circuit Emulator)
 Definition: ICE connects to the actual processor and allows real-time debugging.
 Use Case: Detailed debugging during development.
 Advantages:
 Access to internal processor states
 Real-time code execution and monitoring
 Limitations:
 Expensive equipment
 Complex setup
 Limited support for newer processors
4. Using a Simulator for Hardware
 Definition: Software simulates the hardware environment including CPU, memory, and
peripherals.
 Use Case: Early-stage development and algorithm testing.
 Advantages:
 No need for physical hardware
 Fast prototyping and debugging
 Limitations:
 Not suitable for timing-critical applications
 May not simulate all hardware features accurately

5. Using IDE or Prototyping Tool

 Definition: Integrated Development Environments (IDEs) or prototyping platforms assist in
writing, compiling, and debugging code.
 Use Case: Full-cycle development; beginner-friendly environments.
 Advantages:
 Built-in debugging and simulation tools
 Fast development and deployment
 Limitations:
 Limited to supported platforms
 May abstract away low-level hardware details
Embedded Software Development Tools
 Software Development Lit (SDK)
 Source-code Engineering Software
 RTOS
 Integrated Development Environment
 Prototyper
 Editor
 Interpreter
 Compiler
 Assembler
 Cross Assembler
 Testing and debugging tools
 Locator
Software Development Kit (SDK)
 A collection of tools, libraries, documentation, and sample code tailored for a specific embedded
platform.
 Helps developers interface with microcontrollers, sensors, or communication modules.
 Often includes:
o APIs for hardware access
o Precompiled libraries
o Debugging utilities
o Example projects

Source-code Engineering Software

 Tools that assist in writing, managing, and analyzing source code.
 Includes:
o Version control systems (e.g., Git)
o Static code analyzers
o Code formatters and linters
 Ensures maintainability, readability, and quality of embedded code.

Real-Time Operating System (RTOS)

 A specialized OS designed to meet strict timing constraints.
 Manages tasks, interrupts, and resource allocation in real time.
 Examples: FreeRTOS, VxWorks, RTEMS
 Key features:
o Task scheduling (preemptive or cooperative)
o Inter-task communication (queues, semaphores)
o Deterministic behavior

Integrated Development Environment (IDE)

 A unified interface combining multiple development tools.
 Typically includes:
o Text editor
 o Compiler
o Debugger
o Build automation
 Examples: Keil uVision, MPLAB X, STM32CubeIDE, Eclipse

Prototyper
 Allows rapid development and testing of embedded concepts.
 Can be hardware (e.g., Arduino, Raspberry Pi) or software (e.g., simulation environments).
 Used to validate functionality before full-scale production.

Editor
 A basic tool for writing source code.
 Examples: Geany, Notepad++, VS Code
 Supports syntax highlighting and code formatting for languages like C/C++, Python, or Assembly.

Interpreter
 Executes code line-by-line without compiling it into machine code first.
 Rare in embedded systems due to performance constraints, but used in:
o Scripting environments (e.g., MicroPython)
o Rapid prototyping
 Slower than compiled code but useful for debugging or educational purposes.

Compiler
 Translates high-level code (e.g., C/C++) into machine code for the target processor.
 Performs:
o Syntax checking
o Optimization
o Code generation
 Examples: GCC, IAR Embedded Workbench, Keil C Compiler

Assembler
 Converts assembly language into machine code.
 Used when low-level control over hardware is needed.
 Outputs object files for linking.

Cross Assembler
 Runs on one architecture (e.g., x86 PC) but generates machine code for another (e.g., ARM
Cortex-M).
 Essential for embedded development where the target hardware can't compile code itself.

Testing and Debugging Tools

 Ensure correctness and reliability of embedded software.
 Includes:
o Simulators: mimic hardware behavior
 o Emulators: replicate hardware for real-time testing
o Debuggers: step through code, inspect variables
o Logic analyzers and oscilloscopes: monitor signals
 Examples: GDB, JTAG, ST-Link, Segger J-Link

Locator
 Assigns physical memory addresses to code and data sections.
 Converts relocatable code into a fixed memory image for flashing into ROM or Flash.
 Works alongside linker and cross-compiler to prepare final executable.

Source Code Engineering Tool Features

1. Code Comprehension & Navigation

 Helps developers understand complex codebases quickly.
 Features include:
o Symbol lookup (functions, variables, macros)
o Class hierarchy visualization
o Header file dependency tracking
o Jump-to-definition and reference tracing
2. Editing & Refactoring
 Smart editors with embedded-specific syntax support.
 Features:
o Auto-completion for hardware registers and APIs
o Context-aware suggestions
o Refactoring tools (rename, extract method, etc.)
o Code templates for common embedded patterns
3. Compiling & Cross-Compilation
 Converts source code into machine code for target microcontrollers.
 Features:
o Support for multiple architectures (ARM, RISC-V, AVR)
o Optimization flags for speed, size, or power
o Integration with toolchains like GCC, IAR, or Keil
4. Debugging & Simulation
 Crucial for diagnosing issues on real or simulated hardware.
 Features:
o Breakpoints, watchpoints, and step-through execution
o RTOS-aware debugging (task-level inspection)
o Peripheral register views
o Integration with hardware debuggers (JTAG, SWD)
5. Static & Dynamic Analysis
 Ensures code quality and safety.
 Features:
o Detection of memory leaks, race conditions, and dead code
 o Compliance checks (e.g., MISRA C for automotive)
o Runtime profiling and performance metrics
6. Configuration & Customization
 Allows tailoring the development environment to specific needs.
 Features:
o Enable/disable language features (e.g., virtual functions)
o Custom build configurations
o Plugin support for additional tools (e.g., RTOS, AI modules)
7. Search & Symbol Management
 Efficiently locates and manages code components.
 Features:
o Symbol dependency graphs
o Search and replace across large codebases
o Visibility control (public, private, protected members)
8. Error Detection & Task Cleanup
 Helps maintain clean and efficient code.
 Features:
o Automatic removal of unused or error-prone tasks
o Real-time error highlighting
o Suggestions for code corrections

Emulators and Debuggers

Simulators and emulators are two important tools used in embedded system development.
Simulator is a software tool used for simulating the various conditions for checking the functionality of the
application firmware.
Emulation refers to the ability of a computer program or electronic device to imitate another
Emulator is hardware device which emulates the functionalities of the target device and allows real time
debugging of the embedded firmware in a hardware environment.

Debugger :
A Debugger or debugging tool is a computer program that is used to test and debug other
programs. The code to be examined should be running on an instruction set simulator to identify the fault in
the code because the software problem cannot be identified when we are running it on the original
hardware. The debugger can be used to identify if the program is running correctly, and identify the cause
of failure when it fails. The debugger may be a source-level debugger, or a low-level debugger. If it is a
source-level debugger, the debugger can show the actual position in the original code, when the program
crashes. If it is a low-level debugger or a machine-language debugger, it shows that line in the program.
Catching run-time errors is not as obvious. Most embedded systems do not have a ―screen‖. Hence we
cannot find the run time errors as in general software development.

Debugging an Embedded System

Debugging an embedded system is similar to debugging a host based application. Many
embedded systems are not possible to debug unless they are operating at full speed. Hence debugging of
an embedded system uses host computer. The debugger can exist as two pieces, a debug kernel in the
target and a host application that communicates with it and manages the source database and symbol
tables.

Requirements for Debugging

There are three requirements for debugging an embedded or real-time system. They are Run
control, Memory substitution and real time analysis.
I. Run control is the ability to start, stop, peek, and poke the processor and memory.
II. Memory substitution is replacing ROM-based memory with RAM for rapid and easy code
download, debug, and repair cycles.
III. Real-time analysis is following code flow in real time with real-time trace analysis.

Model Debugging System

Figure. Model Debugging system

Figure shows a model of a debugging system. The data path from the debugging tool represents symbol
table information that allows the mapping of machine level information to source level constructs. Any
debugging system has at least two processes executing:
– Test program and
– The debugger.
One Part of the debugger runs on the host, and the other on the target machine. To make the debugging
system non-intrusive, we need to execute code only at breakpoint (breakpoint is an intentional stopping or
pausing in the program) and run debugger as a separate process and provide separate execution unit to
execute debugger.

Debugging Tools
Debugging is an essential step in the embedded system development process. Figure shows the
different debugging options. It can be done with simulators, Incircuit emulators and using remote target
processors.
Debugging with simulators
Simulator is a host-based program that simulates functionality and instruction set of target
processor. The front-end has text or GUI-based windows for source code, register contents, etc. Simulators
are valuable during early stages of development. Disadvantage of this method is that, it only simulates the
processor, and not the peripherals.

Debugging with Remote Debuggers

Remote Debugger is used to monitor/control embedded SW. It is used to download, execute and
debug embedded software over a communications link. The program running on the host of a remote
debugger has a user interface that looks just like any other debugger that you might have used. The main
debugger screen is usually either a command-line interface or graphical user interface (GUI). GUI
debuggers typically contain several smaller windows to simultaneously show the active part of the source
code, current register contents, and other relevant information about the executing program. Note that in
the case of embedded systems, the debugger and the software being debugged are executing on two
different computer systems. The front-end has text or GUI-based windows for source code, register
contents, etc. Backend provides low-level control of target processor, runs on target processor and
communicates to the front-end over a communication link. Debugger and software being debugged are
executing on two different computer systems. It supports higher level of interaction between host and
target. It allows
- Start/restart/kill, and stepping through program.
- Software breakpoints.
- Reading/writing registers or data at specified address.
Remote debuggers are one of the most commonly used downloading and testing tools during
development of embedded software. This is mainly because of their low cost. Embedded software
developers already have the requisite host computer. In addition, the price of a remote debugger does not
add significantly to the cost of a suite of cross-development tools (compiler, linker, locator, etc.). However,
there are some disadvantages to using a debug monitor, including the inability to debug startup code.
Another disadvantage is that code must execute from RAM. Disadvantage of this system is that it requires
a target processor to run the final software package.

Debugging with (In Circuit Emulator) ICE

In-Circuit Emulator (ICE) takes the place of the target processor. It contains a copy of target
processor, plus RAM, ROM, and its own embedded software. It allows you to examine the state of the
processor while the program is running. It uses the remote debugger for human interface. It supports
software and hardware breakpoints. It has realtime tracing. It stores the information about each processor
cycle which is executed. It allows you to see in what order things happen. ICE provides greater flexibility,
ease for developing various applications on a single system in place of testing that multiple targeted
systems. Disadvantage of this method is that, it is expensive.
Emulation refers to the ability of a computer program or electronic device to imitate another
program or device. An emulator is a piece of hardware/software that enables one computer system to run
programs that are written for another computer system. An incircuit emulator (ICE) provides a lot more
functionality than a remote debugger. In addition to providing the features available with a remote
debugger, an ICE allows you to debug startup code and programs running from ROM, set breakpoints for
code running from ROM, and even run tests that require more RAM than the system contains. The ICE is
itself an embedded system, with its own copy of the target processor, RAM, ROM, and embedded software.
In-circuit emulators are usually expensive. But they are powerful tools, and help significantly for debugging.
Like a debug monitor, an emulator uses a remote debugger for its host interface. In some cases, it is even
possible to use the same debugger frontend for both. But because the emulator has its own copy of the
target processor, it is possible to monitor and control the state of the processor in real time. This allows the
emulator to support such powerful debug features as hardware breakpoints and real-time tracing.
With a debug monitor, you can set breakpoints in your program. Emulators, by contrast, also
support hardware breakpoints. Hardware breakpoints allow you to stop execution in response to a wider
variety of events, not only instruction fetches, but also interrupts and reads and writes of memory. Typically,
an emulator incorporates a large block of specialpurpose RAM that is dedicated to storing information
about each processor cycle executed. Another type of debug tool similar to an ICE is a background debug
mode (BDM), or JTAG debugger. JTAG debuggers are typically less expensive than in-circuit emulators but
offer much of the same functionality. A circuit for emulating target system remains independent of a
particular targeted system and processor.

Figure. In Circuit Emulator (ICE) Diagram

Figure. shows an In Circuit Emulator(ICE) Diagram. ICE interfaces the COM port of a computer. It
emulates target Microcontroller(MCU) IOs. The ICE socket connects MCU externally. It uses computer
developed object files and hex files for the MCU. It uses debugger at the computer developed files for the
MCU application.

Difference in Emulator and ICE

Emulator uses the circuit consisting of the microcontroller or processor itself. The Emulator
emulates the target system with extended memory and with code downloading ability during the edit-test-
debug cycles. ROM Emulator emulates only a ROM. ICE uses another circuit with a card that connects to
target processor through a socket.
Hardware Many hardware emulators are available in the field of development of embedded
systems. In this module we will see ‗Net ROM‘ as an example of hardware emulator.

Figure Net ROM

NetROM is an example of a general class of tools called Emulators. From the point of view of the
target system, the ROM emulator is designed to look like a standard ROM device. A ROM emulator is a
hardware-assist device. The term hardware-assist refers to additional specialized devices that supplement
a software-only debugging solution. ROM emulator has a connector that has the exact mechanical
dimensions and electrical characteristics of the ROM it is emulating. RAM can be written quickly via a
separate channel from a host computer. However, the connector is used to bring the signals from the ROM
socket on the target system to the main circuitry. This circuitry provides highspeed. Thus, the target system
sees a ROM device, but the software developer sees a RAM device. This RAM can have its code easily
modified and allows debugger breakpoints to be set.

Benefits and drawbacks of the Debugging with Emulator

Emulators are the better debugging systems, which have better graphics quality and additional
features than original hardware. It saves states also. Emulators maintain the original look, feel, and
behavior of the embedded system. Even though the cost of developing an emulator is high, it proves to be
the more cost efficient solution over time. Emulators allow software exclusive to one system to be used on
another. It is more difficult to design emulators and it also requires better hardware than the original
system.
Embedded Firmware Design Methodologies :
There exist two basic approaches for the design and implementation of embedded, namely;
 The Super loop based approach
 The Embedded Operating System based approach
The decision on which approach needs to be adopted for firmware development is purely
dependent on the complexity and system requirements
1. Embedded firmware Design Approaches – The Super loop:
 The Super loop based firmware development approach is Suitable for applications that are not
time critical and where the response time is not so important (Embedded systems where
missing deadlines are acceptable).
 It is very similar to a conventional procedural programming where the code is executed task
by task
 The tasks are executed in a never ending loop.
 The task listed on top on the program code is executed first and the tasks just below the top
are executed after completing the first task
 A typical super loop implementation will look like:
1. Configure the common parameters and perform initialization for various hardware
components memory, registers etc.
2. Start the first task and execute it
3. Execute the second task
4. Execute the next task
5. : ….
6. : ….
7. Execute the last defined task
8. Jump back to the first task and follow the same flow.

The ‗C‘ program code for the super loop is given below
void main ()
{
Configurations ();
Initializations ();
while (1)
{
Task 1 ();
Task 2 ();
:
: Task n ();
}
}

Pros:
 Doesn‘t require an Operating System for task scheduling and monitoring and free from OS related
overheads
  Simple and straight forward design
 Reduced memory footprint
Cons :
 Non Real time in execution behavior (As the number of tasks increases the frequency at which a
task gets CPU time for execution also increases)
 Any issues in any task execution may affect the functioning of the product (This can be effectively
tackled by using Watch Dog Timers for task execution monitoring)

Enhancements:
 Combine Super loop based technique with interrupts
 Execute the tasks (like keyboard handling) which require Real time attention as Interrupt Service
routines.

2. Embedded firmware Design Approaches – Embedded OS based Approach:

 The embedded device contains an Embedded Operating System which can be one of:
 A Real Time Operating System (RTOS)
 A Customized General Purpose Operating System (GPOS)
 The Embedded OS is responsible for scheduling the execution of user tasks and the allocation
of system resources among multiple tasks
 It Involves lot of OS related overheads apart from managing and executing user defined tasks
 Microsoft® Windows XP Embedded is an example of GPOS for embedded devices
 Point of Sale (PoS) terminals, Gaming Stations, Tablet PCs etc are examples of embedded
devices running on embedded GPOSs
 ‗Windows CE‘, ‗Windows Mobile‘,‗QNX‘, ‗VxWorks‘, ‗ThreadX‘, ‗MicroC/OS-II‘, ‗Embedded
Linux‘, ‗Symbian‘ etc are examples of RTOSs employed in Embedded Product development
 Mobile Phones, PDAs, Flight Control Systems etc are examples of embedded devices that runs
on RTOSs

Embedded Development Languages/Options

 Assembly Language
 High Level Language
o Subset of C (Embedded C)
o Subset of C++ (Embedded C++)
o Any other high level language with supported Cross-compiler
 Mix of Assembly & High level Language
o Mixing High Level Language (Like C) with Assembly Code
o Mixing Assembly code with High Level Language (Like C)
o Inline Assembly