EMBEDDED FIRMWARE • It is non-alterable by end users to ensure stability and security.

INTRODUCTION: Embedded Firmware Design Considerations (Short)

• Definition: 1. Hardware Understanding:
Embedded firmware refers to the control algorithm (program Know component connections, memory map, I/O ports, and
instructions) and configuration settings that a developer loads register details.
into the program memory of an embedded system. 2. Programming Language:
• Importance: Use Assembly for speed; C/C++ for easier development; mix if
Firmware is an essential and unavoidable part of any embedded needed.
system. Without it, the hardware can't perform its intended 3. Toolchain Selection:
function. Use the right IDE (e.g., Keil, MPLAB, STM32CubeIDE) based on
the processor.
• Development Methods: 4. Power & Performance:
Firmware for embedded systems can be developed in two main Optimize for low power and high efficiency.
ways:
5. Real-Time Needs:
1. High-Level Language (like Embedded C/C++): Use super loop or RTOS based on task complexity.
▪ Programs are written using IDEs 6. Reliability & Security:
(Integrated Development Environments). Ensure stable, bug-free code; protect firmware from user changes.
▪ IDEs include tools such as: Firmware Design Approaches:
▪ Editor (to write code) 1. Super Loop Based Approach:
▪ Compiler (to convert high-level o Suitable for simple systems.
code into machine code) o Main loop continuously checks and performs tasks.
▪ Linker (to combine various code o No multitasking or OS involved.
files) 2. Embedded Operating System Based Approach:
▪ Debugger (to find and fix errors) o Used for complex systems with multiple tasks.
▪ Simulator (to test the program o An RTOS (Real-Time Operating System) manages task
without real hardware) scheduling, timing, and resources.
▪ Examples: Keil for 8051, MPLAB for PIC, o Examples: FreeRTOS, VxWorks, Micrium OS.
STM32CubeIDE for STM32, etc. A) Embedded Firmware Design Approaches – The Super Loop
2. Assembly Language: What is it?
▪ Programs are written using processor- The Super Loop approach is a simple way to structure embedded firmware
specific instructions. where tasks are executed one after another in an infinite loop.
▪ Requires detailed knowledge of the It's suitable for systems where response time is not critical — meaning it's
processor architecture. okay if a task is a bit delayed (e.g., digital clocks, simple sensors, toys).
▪ Provides more control and efficiency but is
more complex and harder to maintain. How It Works
• Code is written sequentially.
• Tasks are placed in a forever running loop (while(1)).
• Each task gets executed one after another, in the order they appear.
• Once the last task finishes, the loop starts again from the first
task.

Steps in Super Loop Implementation

1. Configuration: Set up system-wide settings (e.g., clock speed).
2. Initialization: Prepare memory, I/O pins, and peripherals.
3. Execution Loop:
o Run Task 1 (e.g., read temperature)
o Run Task 2 (e.g., control motor)
o ...
o Run Task n (e.g., update display)
4. Repeat from Task 1 again.

Sample Super Loop Code (in C)

EMBEDDED FIRMWARE DESIGN & DEVELOPMENT c
Role of Embedded Firmware: CopyEdit
• It controls the peripherals (like sensors, actuators, displays, etc.) void main()
of the embedded hardware. {
• Acts as the master brain of the embedded system. Configurations(); // System settings
• Adds intelligence to the product—makes the hardware function as Initializations(); // Hardware setup
per design.
• Once the firmware is embedded, the product begins to function while (1) // Infinite loop
correctly. {
Longevity and Maintenance: Task1(); // e.g., read sensor
• The product works continuously until: Task2(); // e.g., control output
// ...
o A hardware failure occurs, or TaskN(); // e.g., update display
o The firmware gets corrupted. }
• Fixing Issues: }
o For hardware breakdown, replace the faulty Advantages (Pros)
component.
• Simple Design: Easy to write and understand.
o For firmware corruption, re-load the firmware into
memory. • No OS Needed: No complexity or overhead of using an operating
Storage: system.
• Firmware is usually stored in ROM (Read-Only Memory). • Low Memory Use: Best for systems with limited memory.
 Disadvantages (Cons) Example Devices Using Embedded OS-Based Approach:
• Not Real-Time: Task execution is delayed if previous tasks take • Flight control systems (RTOS — need real-time decisions)
too long. • Gaming consoles (GPOS — need rich features)
• Scalability Issues: Adding more tasks makes the system slower. • POS terminals (GPOS — moderate complexity)
• Risky Errors: A bug in one task can affect all others. • Smartphones, Tablets (RTOS or GPOS)
Solution: Use a Watchdog Timer to reset the system if any task gets The Story of Speedo – The Smart Drone
stuck. Once upon a time, a company wanted to build a smart drone named Speedo.
Unlike simple toys, Speedo needed to do many things at once:
Enhancements to Improve Super Loop
• Fly smoothly in the air
• Use Interrupts for real-time tasks:
Tasks that need immediate attention (e.g., button press, sensor
• Read GPS to stay on course
alert) can be handled using Interrupt Service Routines (ISRs). • Communicate with the user’s mobile
• Keep non-critical tasks in the super loop and move urgent tasks to • Record videos in real time
interrupts • Make quick decisions if there’s an obstacle
B) Embedded Firmware Design Approaches – Embedded OS-Based They hired a clever developer named Priya to build Speedo’s brain — the
Approach firmware.
What Is It?
In this approach, the embedded system runs on an Embedded Operating Super Loop? Not Enough!
System (Embedded OS) which is responsible for managing: At first, Priya thought of using the super loop method.
• Task execution (multitasking) But then she realized:
“Speedo is doing many tasks at the same time. If I put them all in one loop,
• CPU scheduling it'll be too slow. What if it hits a tree before I check the GPS again?”
• Memory and resource allocation So she needed something smarter… something that could run many tasks
This makes it suitable for complex systems that need to handle multiple independently.
tasks at once or respond to real-time events.
Enter the Embedded OS!
Types of Embedded OS: Priya decided to use an Embedded Operating System (OS) — like
1. RTOS (Real-Time Operating System) FreeRTOS.
o Designed to respond to events within strict timing She created separate tasks for:
constraints. • One to control motors
o Examples:
• One to read sensors
▪ FreeRTOS
▪ VxWorks • One to track GPS
▪ QNX • One to handle camera
▪ ThreadX • One to talk to the user’s phone
▪ MicroC/OS-II And guess what?
The Embedded OS managed when and how long each task ran — like a
▪ Embedded Linux smart manager giving time to each worker at the right moment!
▪ Symbian
o Used in: Mobile phones, PDAs, flight control OS Choices She Considered:
systems, industrial robots.
2. GPOS (General Purpose Operating System) Customized for • For real-time speed, she chose RTOS like:
Embedded Devices o FreeRTOS
o A lighter version of regular desktop OS tailored for o VxWorks
embedded use. o ThreadX
o Examples: • For other devices like smart displays or tablets, she could use
▪ Windows XP Embedded GPOS like:
▪ Windows CE o Windows CE
▪ Windows Mobile o Embedded Linux
o Used in: POS terminals, gaming consoles, smart
appliances, tablet PCs. What She Gained:
• Multitasking: All parts of Speedo could run in parallel
How It Works: • Real-time response: Obstacle avoidance happened instantly
• Developer writes each task (like reading a sensor, updating a • Modularity: Each task was like a separate mini-program — easier
display, communicating via Bluetooth). to manage
• The Embedded OS handles: Embedded Firmware Development Process
o Which task runs when (scheduling) Requirement Analysis
o How long it runs Architecture & Design
Modeling (Optional)
o Which resources (memory, timers, etc.) it can use
Coding
Compilation
Advantages: Simulation (Optional)
• Supports multitasking. Firmware Programming
• Handles real-time needs (in RTOS). Debugging
Testing
• Provides better structure and modularity for complex projects.
Optimization
Deployment
Disadvantages: Maintenance
• Requires more memory and processing power. The Story of Smarto — The Smart Fan
• Adds OS overhead (extra system load). Once upon a time, a company wanted to build a smart fan called Smarto — a
• More complex to develop and debug than the super loop fan that could adjust its speed based on room temperature and could be
approach. controlled via remote.
They hired an embedded system developer named Ravi to bring Smarto to
life. Let’s see how Ravi developed the firmware — the "brain" of Smarto.
 • Provides access to low-level hardware features with easier syntax
Step 1: Understanding Smarto’s Needs than assembly.
Ravi first sat down with the product team to understand what Smarto should • Supported by many cross-compilers.
do: b) Embedded C++ (Subset of C++)
• Sense temperature • Adds object-oriented features to C.
• Control motor speed • Useful for modular and complex firmware design.
• Receive commands from a remote • Used in systems that need reusable code and abstractions.
He wrote down all the requirements — this was the requirement analysis c) Other High-Level Languages
stage.
• Any language with a cross-compiler for the target microcontroller
can be used (e.g., Python for MicroPython boards, Rust for bare-
Step 2: Planning the Brain
metal systems).
Next, Ravi designed how the firmware (Smarto’s brain) would work:
• One part would read the temperature sensor 3. Mix of Assembly and High-Level Language
• Another part would control the motor speed Combines the performance of assembly with the ease of C/C++.
• Another part would handle remote signals a) Mixing C with Assembly
He decided to use the super loop approach because Smarto wasn’t too • C used for general logic
complex. • Assembly used where precise timing or speed is needed
b) Mixing Assembly with C
Step 3: Drawing the Logic
• Assembly files called from a C program (or vice versa)
Before jumping into code, Ravi drew some flowcharts — like a map of what
c) Inline Assembly
the firmware should do step by step. This helped him avoid confusion later.
• Embedding small chunks of assembly code within a C function
Step 4: Writing the Code • Allows for efficient handling of critical tasks without separate
Ravi opened his IDE (Keil) and started writing Smarto’s firmware in assembly files
Embedded C. • The Story of TinyBot – The Smart Mini Robot
• He initialized the sensor, motor, and remote modules • TinyBot was a smart little robot that could walk, talk, sense
• Wrote the logic to control fan speed based on temperature obstacles, and blink its lights. But to do all this, TinyBot needed a
• Added checks for low battery and error handling brain — firmware!
• The developers sat down to decide which language to use to build
Step 5: Testing in a Virtual World TinyBot’s brain. They had a few choices:
Before putting the code on the actual Smarto fan, Ravi tested it using a •
simulator in his IDE. The virtual Smarto responded well — things looked • 1. Assembly Language – The Old Expert
good! • One senior developer said,
Step 6: Giving Smarto its Brain • “Let’s use Assembly! It’s super fast and talks directly
to the hardware.”
Ravi took the .hex file and used a programmer device to load the firmware
into the microcontroller of the Smarto fan. • They used it for TinyBot’s motor control so it could move quickly
Now, Smarto had a brain! without delays.
But Assembly was hard to write and read, so they used it only
Step 7: Debugging Smarto where speed really mattered.
Ravi tested the real Smarto. Uh-oh! It didn’t respond to remote commands. He •
connected his debugger, found a tiny mistake in the IR receiver code, fixed it, • 2. Embedded C – The All-Rounder
and reloaded the firmware. • Another developer suggested,
Now Smarto was working perfectly!
• “Let’s write most of TinyBot’s code in Embedded C.
It’s easier, faster to develop, and works well with
Step 8: Final Touches hardware too!”
Ravi optimized the code to use less memory and power — Smarto could now
run longer on backup power and respond faster. • So, TinyBot’s sensor reading, LED blinking, and basic logic
were written in Embedded C — simple and efficient!
Step 9: Launch Day •
The final firmware was locked into Smarto's ROM. Ravi handed over the code • 3. Embedded C++ – The Organizer
and documentation. Smarto was now ready for the market! • The third developer added,
• “We can use C++ for TinyBot’s camera and voice
Step 10: Keeping Smarto Smart modules. C++ helps organize code neatly using
If future updates were needed, Ravi had a plan — Smarto could be re- objects.”
programmed using a USB port.
• This made TinyBot’s complex parts modular and reusable.
And Smarto lived smartly ever after…
Embedded Firmware Development Languages/Options
•
• 4. Mix of C and Assembly – The Perfect Teamwork
1. Assembly Language
• Finally, the developers said,
• A low-level language that uses processor-specific instructions.
• “Let’s mix C for logic and Assembly where we need
• Offers direct hardware control, speed, and efficiency.
speed.”
• Requires deep knowledge of processor architecture.
• In some parts, they even wrote inline assembly inside C functions
• Mostly used for: for fast math operations.
o Time-critical operations
o Memory-constrained systems
2. High-Level Languages
Used for ease of development, readability, and faster coding.
a) Embedded C (Subset of C)
• Most widely used language in embedded systems.
 (A) Assembly Language – Key Points • Syntax: must start with a letter, end with a colon (:), and can
include numbers or _.
What Is Assembly Language?

• Assembly language is a human-readable form of machine

language.
• Machine language consists of 1s and 0s (binary) and is directly
understood by the processor.
• Assembly provides mnemonics (short words) to represent binary
machine instructions.

• Assembly language is processor/controller dependent.

• A program written for one processor (like 8051) won’t work on
another (like ARM).

Role of Assembler

• An assembler converts assembly language mnemonics into

machine code.

Instruction Format

Each assembly instruction usually contains:

nginx

CopyEdit

LABEL OPCODE OPERAND ; COMMENT

• LABEL (optional): Name or address used to reference code/data

• OPCODE: The instruction (e.g., MOV, ADD)
• OPERAND: The data or registers involved (e.g., A, #30)
• COMMENT: Notes ignored by the assembler (starts with ;)

Example (8051 Microcontroller)

Instruction:

MOV A, #30

• Opcode: MOV A → move value to register A

• Operand: #30 → the immediate value (30 in decimal)
• Machine code:
o 01110100 = MOV A
o 00011110 = 30
→ Together: 01110100 00011110

Labels

• Used to name a memory location or section of code.

• Helps jump to a location without remembering addresses.