Embedded Firmware Design and Development

• Firmware is a type of software that provides low-level control for a device’s

specific hardware.
• When this firmware is embedded into a dedicated hardware system (e.g.
controller, or IoT device), it’s called embedded firmware.
• Embedded firmware refers to the specialized software programmed directly into
hardware devices (usually in microcontrollers, FPGAs, or SoCs) to control their
functions.
• It acts as the bridge between the hardware and higher-level software, enabling
the device to perform its intended tasks reliably and efficiently.
 Embedded Firmware Design approaches

• The Super Loop Model Based Approach

• The Embedded Operating System Based Approach
 The Super Loop Model Based Approach

• The Super Loop Model Based Approach

• The Embedded Operating System Based Approach
 The Super Loop Model Based Approach
• A super loop is a continuous, infinite loop that executes tasks one after another
in a fixed sequence. It’s often used in bare-metal systems (systems running
directly on hardware without an OS).
• It is adopted for applications that are not time critical and where the response
time is not so important.
• The firmware execution flow will be-
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. .
5. .
6. .
7. Execute the last task
8. Jump back to the first task and follow the same flow.
 The Super Loop Model Based Approach
• The task is running in an infinite loop.
• To come out of the infinite loop, either hardware reset or interrupt assertion is required.
• Hardware reset brings the program execution back to the main loop.
• Whereas the interrupt request suspends the task execution temporarily and performs the
corresponding interrupt routine and on the completion of the interrupt routine it restarts
the task execution from the point where it is got interrupted.

• The super loop based design doesn’t require an operating system, since there
is no need for scheduling which task is to be executed firsta nd assigning
priority to each task.
• E,g, reading / writing data from a card using a card reader. (check presence of
card, authenticate user, perform read/write etc. in sequence)
 The Super Loop Model Based Approach
Advantages
• Simple – Easy to design, code, and debug.
• Deterministic – The order of execution is known.
• Low Overhead – No RTOS scheduler or multitasking overhead.
• Good for small systems – Ideal for low-cost, low-power devices.

Disadvantages
• No Robust– Failure in any part of the single task may affect the entire system
• Lack of real timeliness – repeated execution of single task increases time to execute it
• Missing out tasks– one task is repeated inside infinite loop, few tasks may be missed out
 The Embedded Operating System based Approach

• General Purpose Operating System

• Real Time Operating System
 General Purpose Operating System (GPOS) based design
• It is like conventional PC based design.
• Applications can run on the top of GPOS.
• E.g. PDA which contains Microsoft Windows XP Embedded OS.
Advantages
• Supports multiple processes and applications.
• Built-in support for networking, graphics, filesystems
• Easier porting of high-level apps (Python, C++, Java)
• Rich ecosystem (drivers, libraries)
Drawbacks
• Non-deterministic response (not suitable for strict real-time tasks)
• High overhead and longer boot time
• Requires more RAM/Flash
• Harder to meet timing constraints
 Real-Time operating System (RTOS) based design
• It is employed in embedded products demanding real time response.
• Responds in timely and predictable manner.
• E.g. Windows CE, Embedded Linux, Symbian etc.
Advantages
• Deterministic behavior — guarantees response within deadlines
• Efficient multitasking with priority scheduling
• Low memory usage
• Fast interrupt response
Limitations
• Limited functionality (no GUI, advanced file systems unless added)
• Requires careful task design
• More complex debugging and synchronization
• Not suited for large, multi-user applications
 Embedded Firmware Development Languages

• Assembly Language based Development

• High Level Language based Development
 Assembly Language based Development
• “Assembly language” is the human readable notation of “machine language” whereas “machine language” is the
processor understandable language.
• Processor understands only binaries i.e. 0’s and 1’s.
• Machine language is made readable by using specific symbols called “mnemonics”.
• Assembly language is often used in writing the low level interaction between the operating system and the
hardware.
• Instruction in assembly language is of form:
LABEL OPCODE OPERAND COMMENTS

• Assemble language program file is saved using .asm and .src extension.
• Assembly language supports modular programming, where entire code is divided into submodules and each
module is made reusable saved by extension .asm or .src.
Source File to Object File Translation
 Library File Creation and Usage

• Libraries are specifically formatted, ordered program collection of object modules that may be used by the linker at the

later time.

• Library files are generated with .lib extension.

• If you don’t want to reveal the source code behind the various functions and at the same time you want them to be

distributed to application developers for making use of them in their applications, you can supply them as library files.
 Linker and Locater

• Linker and Locater is the another software utility responsible for linking various object modules in multi-module

project and assigning absolute address to each module.

• Linker generates an absolute object module by extracting the object module from the library and object files

created by the assembler.

• It is the responsibility of linker to resolve external dependencies of external variables and functions declared in

the various modules.

 Object to Hex file converter

• This is the final stage in the conversion of Assembly Language (Mnemonics) to machine understandable

language (Machine Code).

• Hex file is the representation of the machine-code and the hex file is dumped into the code memory of the

processor / controller.
 Advantages of Assembly Language Based Development
• Efficient Code Memory and Data Memory Usage (Memory Optimization)
❑ Since the developer is well versed with the target processor architecture and memory organization, optimized code can be
written for performing operations.
❑ This leads to efficient utilization of code and data memory.

• High Performance
❑ Optimized code results in improved system performance.

• Low Level Hardware Access

❑ Low level device specific operation support is not commonly available with most of the high level language cross compilers, e.g.
Accessing device specific registers from the operating system kernel, low level interrupt control routine etc.

• Code Reverse Engineering

❑ Though most of the products employ code memory protection, if it may be possible to break the memory protection and read
the code memory, it can be easily converted into assembly code using a dis-assembler program for the target machine.
 Disadvantages of Assembly Language Based Development
• High Development Time
❑ Assembly language is harder to program than High level Language.
❑ The developer must pay attention to more details and must have thorough knowledge of the architecture, memory organization
and register details of the target processor in use.
❑ Number of lines of code is more than high level language .

• Developer Dependency
❑ There is no common rule for developing assembly language-based applications whereas high level languages follows a certain
rule for application development.
❑ If the application developed by the developer is not documented properly, then it is not easily modifiable and upgradable.

• Non-Portable
❑ Assembly code written for one target processor may be not be valid for another target processor. Hence assembly language
codes are not portable.
 High Level Language based Development

High level language with a supported cross compiler convert the application developed in high level language
to the target processor specific assembly code. E.g. HLL- C, C++, Java etc.
Source File to Object File Translation
 Advantages of Assembly Language Based Development
• Reduced Development Time
❑ Since the developer need not be well versed with the target processor architecture and memory organization, development
time increases.
❑ The number of lines of code is less.

• Developer Independency
❑ The syntax used by most of the high-level language are universal so a program written in HLL can be easily understood by the
other persons and is easily modifiable and upgradable.

• Portability
❑ Target application written in high level languages are converted to the target processor/ controller understandable format by
cross compilers.
❑ If the cross-compilers supports a variety of processor/controller architecture, the code becomes portable.
 Disadvantages of Assembly Language Based Development

• The cross-compilers available for high level language may not be efficient for generating optimized code for

target processor architecture.

• The IDE (Integrated Development Environment) for HLL development tools is costlier than assembler.
 Mixing Assembly and HLL

• Mixing Assembly Language with HLL

• Mixing HLL with Assembly Language

 Mixing Assembly Language with HLL
• Entire program is written in HLL like ‘C’ but only part of the program that requires interrupt Service Routine or peripheral
access etc.
• Passing parameter to the assembly routine and returning values from the assembly routine to the caller C function and the
method of invoking the assembly routine from the C code is cross compiler dependent.
 Mixing HLL with Assembly Language
Scenarios when the mixing is required:

• The source code is available in assembly language, and a routine is written in high level language link “C” needs to be included
to the existing code.
• The entire source code is planned in Assembly code for various reasons like optimized code, optimal performance, efficient
code memory utilization etc. but some portion of the code may be very difficult and tedious to code in assembly.
• To include built in library functions written in “C” language provided by cross compilers.
 Difference between C and Embedded C
Point C Embedded C

Definition General-purpose programming language Extension of C for embedded system programming

Target Platform Computers, servers Microcontrollers (8051, PIC, AVR, ARM)

Execution Environment Runs under an OS Usually no OS; bare-metal or RTOS

Memory Availability Large memory available Very limited RAM/Flash

Hardware Access No direct hardware access Direct access to registers and ports

Input/Output Console/file I/O GPIO, ADC, UART, SPI, I2C

Timing Requirements Not strict Highly time-critical (real-time)

Program Structure Program runs and terminates Infinite loop (super loop)

Compiler/Tools GCC, Clang, Visual Studio Keil, MPLAB, IAR, AVR-GCC

Output File Executable (.exe) Firmware (.hex/.bin)

Portability Highly portable Less portable (MCU-specific)

Resource Constraints Minimal Very strict (memory, power, speed)

Concurrency Uses OS threads Uses interrupts, ISRs, timers

Use of Bitwise Ops Limited Very high (register-level control)

Debugging Software debuggers Hardware debuggers (JTAG/SWD)

 Compiler Vs Cross Compiler
Point Compiler Cross Compiler

Definition Converts source code into machine code for the same system where it is compiled Converts source code into machine code for a different target system/processor

Host & Target Host system = Target system Host system ≠ Target system

Use Case Used for normal PC software development Used for embedded system firmware development

Example Target x86 PC generating x86 executable Windows/Linux PC generating ARM, AVR, PIC, 8051 binary

Output Format Executable files (.exe, .out) Firmware files (.hex, .bin)

Toolchain Components Compiler, linker, loader Compiler, assembler, linker, hex converter

Hardware Dependency Minimal hardware dependency Strong hardware/architecture dependency

Designed For Native applications Cross-architecture embedded applications

Resource Constraints Usually no strict constraints Must consider target MCU constraints (RAM, Flash)

Examples GCC (native), Clang, MSVC ARM GCC (arm-none-eabi-gcc), Keil C51, MPLAB XC8, AVR-GCC

Typical Platform Desktop or laptop Desktop/laptop generates code for microcontroller boards

Debugging Output Standard debugging symbols Target-specific debugging symbols (ELF + DWARF)

Binary Execution Runs directly on host Cannot run on host; must be flashed to MCU

Role in Embedded System Not used for MCU firmware Essential for generating firmware for microcontrollers