Blog

Master Design Architecture using UML Diagrams in Software Engineering (2026)

Design Architecture using UML Diagrams in Software Engineering : When it comes to building robust and maintainable software, having a clear understanding of design and architecture is crucial. The design phase translates system requirements into a blueprint, laying the foundation for code development. Architecture, on the other hand, outlines the overall structure and behavior of the system, ensuring it can meet both functional and non-functional requirements efficiently.

One powerful tool used in software design and architecture is the Unified Modeling Language (UML). UML provides a standard way to visualize the design of a system through different types of diagrams, each representing different aspects of the system. In this article, we will dive into four essential UML diagrams—Use Case, Class, Sequence, and Activity Diagrams—to understand how they help in the design and architecture of software systems.

Design Architecture using UML

1. Use Case Diagram

A Use Case Diagram is a visual representation of the system’s functional requirements. It shows the interactions between users (or other systems) and the system itself. These interactions are represented as use cases, which depict specific tasks or operations that the system can perform.

Components:

Actors: Represent the external entities (users or systems) that interact with the system.
Use Cases: Represent the various functions or processes that the system performs in response to the actors’ actions.
System Boundary: Defines the scope of the system, indicating what is inside the system and what lies outside.

Example:

Consider a Library Management System:

Actors: Librarian, Member, Administrator.
Use Cases: Borrow Book, Return Book, Add New Book, Search Catalog, Update Member Information.

The Use Case Diagram for this system would illustrate how each actor interacts with the system and the functionalities they can access.

2. Class Diagram 📦

A Class Diagram is one of the most important diagrams in object-oriented design. It provides a static view of the system by showing the classes, their attributes, methods, and the relationships between them.

Components:

Classes: Represent the objects or entities in the system, defined by their attributes and methods.
Associations: Indicate relationships between classes, such as one-to-one, one-to-many, or many-to-many.
Inheritance: Denotes the relationship where one class (the subclass) inherits attributes and behaviors from another (the superclass).
Multiplicity: Indicates how many instances of a class can be associated with an instance of another class.

Example:

For the Library Management System, the class diagram might include:

Classes: Book, Member, Librarian, Transaction.
Attributes: Book (title, author, ISBN), Member (name, membership ID), Transaction (date, book).
Methods: Borrow(), Return(), Search().

3. Sequence Diagram ⏳

A Sequence Diagram provides a dynamic view of the system by showing how objects interact with each other in a particular scenario over time. It emphasizes the sequence of messages exchanged between objects to achieve a specific functionality.

Components:

Objects: Represent the entities involved in the interaction.
Messages: Represent the interactions between objects, typically method calls or data exchanges.
Lifelines: Vertical dashed lines representing the time span during which an object exists in the interaction.
Activation Bars: Rectangles on the lifeline, showing when an object is active and processing a message.

Example:

In the Library Management System, a sequence diagram might illustrate how a Member interacts with the system to borrow a book:

The Member sends a borrow request to the Librarian object.
The Librarian checks if the book is available.
The Member receives confirmation, and the book is borrowed.

The sequence diagram ensures that the communication flow is understood and accurately modeled for that specific scenario.

4. Activity Diagram 🔄

An Activity Diagram models the workflow or the business process in the system. It shows the flow of control from one activity to another and helps in understanding the sequence of operations or the steps involved in a process.

Components:

Activities: Represent tasks or actions performed in the system.
Transitions: Indicate the flow between activities.
Decision Nodes: Represent points where the flow splits based on a condition.
Start/End Points: Indicate the entry and exit points of the activity.

Example:

For the Library Management System, an activity diagram for borrowing a book might include:

Start: The member logs into the system.
Decision: Check if the book is available.
- Yes: Proceed to borrow.
- No: End.
Borrow Book: The system processes the borrow request.
End: The transaction is complete.

Why Use UML Diagrams in Software Design?

Visualization: UML diagrams provide a clear, graphical representation of a system, making it easier for stakeholders to understand the system’s design and architecture.
Communication: They serve as a common language between developers, business analysts, designers, and clients, ensuring everyone is aligned.
Documentation: UML diagrams help in documenting the design process, providing valuable references for future development or maintenance.
Problem-solving: These diagrams help identify potential issues early in the design phase by visualizing complex relationships and interactions.

💛 Support Embedded Prep

If you find our tutorials helpful and want to support our mission of sharing high-quality embedded system knowledge, you can contribute by buying us a coffee. Every small contribution helps us keep creating valuable content for learners like you. ☕

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

UML State Machine Diagrams

In software and systems design, understanding how an object behaves in response to different events is crucial. This is where UML State Machine Diagrams come into play. These diagrams visualize how an object changes state based on events, helping designers model dynamic behaviors effectively.

What is a UML State Machine Diagram?

A UML (Unified Modeling Language) State Machine Diagram—also known as a statechart diagram—is used to describe the lifecycle of an object. It shows:

Different states an object can occupy.
Transitions between states triggered by events.
Actions executed during state changes or while in a state.

These diagrams are particularly useful in real-time systems, embedded systems, protocols, workflow modeling, and any domain where the object’s state plays a key role.

Key Concepts and Terminology

1. State

A condition or situation during the life of an object where it satisfies some condition or waits for an event.

Initial State: Represented by a filled black circle (●). It marks the starting point of the state machine.
Final State: Represented by a bullseye (◎). It indicates the end of the object’s lifecycle.
Composite State: A state that contains sub-states, useful for representing complex behavior.
Substate: A state nested inside a composite state.

2. Transition

A directed arrow (→) that shows the movement from one state to another. It typically includes:

Event [Guard] / Action

Event: The trigger for the transition.
Guard (optional): A condition that must be true for the transition to occur.
Action (optional): An operation that occurs during the transition.

3. Action vs Activity

Action: Executes instantaneously as a result of a transition.
Activity: Represents longer-running behavior during a state.

4. Entry/Exit Actions

entry / action: Executed when entering a state.
exit / action: Executed when exiting a state.

Example: Turnstile System

Let’s model a simple turnstile gate:

States:

Locked
Unlocked

Events:

Coin (inserted)
Push (someone tries to go through)

State Machine Diagram:

● ───> Locked
       Coin / unlock
Locked ────────→ Unlocked
       Push / alarm
Unlocked ───────→ Locked
       Push / lock
◎

Description:

Initially, the turnstile is Locked.
Inserting a Coin unlocks it.
A Push without a coin triggers an alarm.
Once Pushed in the Unlocked state, it goes back to Locked.

When to Use State Machine Diagrams

Use state machine diagrams when:

Modeling reactive systems that respond to external/internal events.
Describing workflow systems, like approval processes or UI interactions.
Visualizing protocols or communication sequences.
Implementing finite state machines (FSMs) in embedded systems.

Best Practices

Keep states simple and meaningful.
Use guard conditions to handle conditional transitions.
Prefer entry/exit actions for reusable logic.
Break down complex systems using composite states.
Ensure completeness—every event in a state should be handled or explicitly ignored.

Tools That Support UML State Diagrams

Popular modeling tools include:

Visual Paradigm
Lucidchart
StarUML
Enterprise Architect
Draw.io

These tools often support code generation for certain languages based on the state machine logic.

Understanding Finite State Machines (FSM)

In computing and electronics, Finite State Machines (FSMs) are fundamental models used to design systems that react to inputs based on their current state. From vending machines to traffic lights and embedded systems, FSMs power countless real-world applications.

What is a Finite State Machine?

A Finite State Machine (FSM) is a computational model consisting of a finite number of states, transitions between those states, inputs that trigger transitions, and optional outputs. At any given time, the system is in exactly one state, and changes to another state based on inputs and predefined rules.

Key Components of FSM

States: The various modes in which the machine can exist (e.g., Idle, Running, Stopped).
Initial State: The state where the system starts.
Input: External data or events that trigger state transitions.
Transition Function: Rules that define how the system moves from one state to another based on input.
Final (Accepting) State (optional): A special state that indicates completion or acceptance.
Output (for Mealy/Moore machines): The actions produced by the machine depending on its state or transition.

Types of Finite State Machines

1. Moore Machine

Output depends only on the current state.
Output is associated with the state.

2. Mealy Machine

Output depends on both the current state and the input.
Output is associated with transitions.

Feature	Moore Machine	Mealy Machine
Output	Based on state	Based on state + input
Simplicity	Easier to design and debug	More responsive
States	May require more states	Can be more compact

Real-World Example: Traffic Light Controller

States:

Green
Yellow
Red

Input:

Timer

FSM Logic:

Start in Red.
After timer expires, go to Green.
Then Yellow.
Then back to Red.

Transition Table:

Current State	Input (Timer)	Next State	Output
Red	Expired	Green	Go
Green	Expired	Yellow	Slow Down
Yellow	Expired	Red	Stop

Applications of FSM

FSMs are used in a wide variety of domains:

Embedded Systems: Control units, protocol design, device firmware.
Game Development: NPC behaviors, game states (e.g., Start, Play, Pause, Game Over).
UI Navigation: Button clicks, menu transitions.
Digital Circuits: Sequential logic design using flip-flops.
Compilers: Lexical analysis using deterministic FSMs (DFAs).

FSM vs UML State Machine Diagram

While both model state behavior, they serve slightly different purposes:

Aspect	FSM	UML State Machine Diagram
Usage	Code-level modeling	High-level design & documentation
Detail Level	Simple state-input-output logic	Detailed with entry/exit actions
Visual Representation	Typically tabular or minimalistic	Rich, diagrammatic (UML-based)
Support for Hierarchy	No (basic FSM)	Yes (composite, nested states)

Benefits of Using FSMs

Predictable Behavior: Every input has a well-defined outcome.
Modularity: Easy to extend and maintain.
Formal Verification: Well-suited for testing and validation.
Code Generation: FSMs can be translated into actual program logic easily.

FSM in Embedded C Example

typedef enum { RED, GREEN, YELLOW } State;
State currentState = RED;

void timerExpired() {
    switch (currentState) {
        case RED: currentState = GREEN; break;
        case GREEN: currentState = YELLOW; break;
        case YELLOW: currentState = RED; break;
    }
}

Software Architecture Patterns

When building software — whether it’s a web app, an embedded system, or a desktop application — organizing the code in a clean, scalable way is critical. That’s where Software Architecture Patterns come into play.

Let’s explore the most common patterns:

1. Layered Architecture (aka n-tier Architecture)

What It Is:

This pattern organizes the system into layers. Each layer has a specific responsibility and only communicates with adjacent layers.

Typical Layers:

Presentation Layer – UI, user interaction
Application Layer – Coordinates business logic
Business Logic Layer – Implements core rules and logic
Data Access Layer – Handles storage and retrieval

Example:

Imagine a simple banking app:

The UI shows account balance (Presentation)
It asks the application layer to fetch it
Business logic layer checks if the user is authenticated
Data access layer gets balance from the database

Pros:

Easy to understand and maintain
Good separation of concerns
Common in enterprise applications

Cons:

Can become rigid; layers depend on each other too much
Might have performance overhead

2. Modular Architecture

What It Is:

Breaks the system into independent modules that can be developed and deployed separately.

Each module has a clearly defined interface and can be reused or swapped without affecting the rest of the system.

Think of it like:

LEGO blocks — you can combine different pieces to build various things.

Example:

In an e-commerce platform:

A Payment Module
A User Authentication Module
A Product Catalog Module

Each can be worked on independently by different teams.

Pros:

High flexibility and reusability
Easier testing and maintenance
Ideal for microservices and plugin-based systems

Cons:

Can be harder to integrate
Requires careful interface design

3. Event-Driven Architecture

What It Is:

The system reacts to events. Components send and listen for events asynchronously.

Example:

In an IoT system:

A sensor detects temperature rise and emits an event
A controller receives the event and turns on a fan

Pros:

Highly decoupled and scalable
Works well in real-time systems

Cons:

Difficult to debug
Event flow can become complex

4. Microkernel Architecture (aka Plugin Architecture)

What It Is:

You build a core system and allow new features to be added as plugins without changing the core.

Example:

Think of a media player:

The core handles playback
Plugins add support for MP3, MP4, subtitles, streaming, etc.

Pros:

Very extensible
Good for systems that evolve over time

Cons:

Plugin interactions can get messy
Version management is tricky

5. Microservices Architecture

What It Is:

The application is split into small services, each running independently and communicating via APIs (usually HTTP/REST).

Example:

A ride-sharing app:

A service for user profiles
A service for ride matching
A service for payment processing

Each can be scaled or updated without touching the others.

Pros:

Flexible and scalable
Independent deployment

Cons:

Complex deployment and networking
Requires DevOps maturity

6. Client-Server Architecture

What It Is:

Divides the system into clients (requesters) and servers (responders). The client asks for services; the server provides them.

Example:

A web browser (client) requests a web page from a web server.

Pros:

Simple and widely used
Centralized server simplifies management

Cons:

Server is a single point of failure
Limited scalability unless load-balanced

7. Service-Oriented Architecture (SOA)

What It Is:

An evolution of modular and client-server patterns where services expose well-defined interfaces and are loosely coupled.

It’s the architectural grandparent of microservices.

Example:

A travel booking platform with services for:

Flight booking
Hotel reservation
Customer reviews

Each service communicates via a standard protocol (like SOAP or REST).

Pros:

Reusability of services
Technology-agnostic

Cons:

Can become heavy with enterprise-level tools
More suitable for large applications

Summary Table

Pattern	Best For	Key Benefit
Layered	Web and enterprise apps	Clear separation of concerns
Modular	Embedded, large systems	High maintainability
Event-Driven	IoT, real-time apps	Decoupling and scalability
Microkernel	Extensible desktop apps	Easy feature addition
Microservices	Scalable cloud apps	Independent deployment
Client-Server	Web systems, databases	Centralized control
Service-Oriented (SOA)	Enterprise systems	Reusable, loosely coupled services

When to Use Which?

Use Layered if you’re starting small and want structure.
Use Modular when building for flexibility and reuse.
Use Microservices if scaling and team independence matter.
Use Event-Driven for responsive, real-time behavior.
Use Microkernel when plugins/extensions are core to your product.
Use Client-Server for simple request-response setups.
Use SOA for interoperable services in enterprise ecosystems.

Where We Design Architecture for Embedded and Real-Time System Design Concepts

Designing the architecture for embedded and real-time systems is a foundational step that determines how reliable, efficient, and responsive your system will be. Whether you’re building a microwave controller or an automotive ECU (Electronic Control Unit), understanding where and how the architecture is designed is crucial.

Let’s explore this step by step in a clear and beginner-friendly way.

What Is System Architecture?

System architecture is a high-level blueprint of how your system will work. It defines:

What components your system will have (e.g., sensors, processors, actuators)
How these components interact
What software modules are needed
How timing, memory, and communication will be handled

Think of it as drawing the floor plan before constructing a building. It helps avoid chaos later.

Where Does Architecture Design Fit in the Development Process?

Architecture design is done early in the development lifecycle, right after requirements are gathered. Here’s a simplified flow:

1. Requirements → 2. Architecture Design → 3. Detailed Design → 4. Implementation → 5. Testing → 6. Deployment

In embedded and real-time systems, early architecture design is critical because:

Hardware choices might be fixed or constrained
Timing and reliability requirements are strict
You can’t afford delays or software crashes

Where Do We Design the Architecture?

We design embedded and real-time architecture in both hardware and software domains. Let’s break them down.

1. Hardware Architecture Design

Where?

On paper (initially), then using tools like OrCAD, KiCAD, or Altium Designer
Sometimes with simulation tools like Proteus or MATLAB Simulink

What is decided?

Type of microcontroller or processor (e.g., ARM Cortex-M4, ESP32)
Memory size (RAM, Flash)
Input/output interfaces (GPIOs, UART, SPI, I2C, CAN)
Power source and regulators
Sensor and actuator connections
Communication methods (Bluetooth, Ethernet, Wi-Fi)

Why important?

This hardware becomes the foundation your software will run on
Incorrect hardware decisions can lead to major rework

2. Software Architecture Design

Where?

On UML tools (like Enterprise Architect, Lucidchart, or Visual Paradigm)
In spreadsheets, flowcharts, or even code comments (early drafts)
Often documented in Software Architecture Documents (SAD)

What is decided?

Operating system: Bare-metal or RTOS (like FreeRTOS, QNX, VxWorks)
Task or thread design: What tasks run, their priority, timing, and how they communicate
Driver layers: HAL (Hardware Abstraction Layer), Middleware
Application logic: State machines, interrupt handling, timers
Memory map and stack/heap size
Error handling, watchdog, fault tolerance

Why important?

Ensures that real-time constraints (deadlines) are met
Prevents bugs due to race conditions, priority inversion, or memory issues

Example: Real-Time Temperature Monitoring System

Let’s imagine designing the architecture for a system that reads temperature every second and triggers a fan if it crosses a threshold.

Hardware Architecture:

Microcontroller: STM32F103 (ARM Cortex-M3)
Sensor: DHT11
Fan: Controlled by relay
Power: 5V battery

Software Architecture:

RTOS: FreeRTOS
Tasks:
- ReadTempTask: Reads temperature every 1 sec
- ControlFanTask: Checks temp and turns fan ON/OFF
Communication: Queues between tasks
Watchdog Timer: Ensures system restarts if a task hangs

Key Concepts in Real-Time Architecture Design

Concept	Meaning	Why It Matters
Task Scheduling	How tasks are run and switched	Ensures real-time deadlines
Inter-task Communication	How tasks talk (queues, semaphores)	Avoids data corruption
Interrupt Handling	Responding to external events	Needs to be fast and safe
Memory Management	RAM, stack, heap usage	Prevent crashes and overflows
Determinism	Predictable execution timing	Core to real-time guarantees

Common Mistakes in Architecture Design

Not considering real-time constraints early
Overloading the main loop without RTOS
Using too much memory or dynamic allocation
No fallback or error handling
Poor separation between hardware and application logic

Tools That Help Design Architecture

Purpose	Tool Examples
Drawing Diagrams	Lucidchart, Draw.io, Microsoft Visio
UML & Modeling	Enterprise Architect, Modelio
Hardware Design	KiCAD, Altium, Proteus
Real-time Modeling	Simulink, Rhapsody
Code & Documentation	Doxygen, Git, VS Code

Conclusion

Designing the architecture for embedded and real-time systems is not just a planning step—it’s the foundation for everything that follows. Whether you’re working with a simple microcontroller or a complex automotive system, good architecture:

Saves time
Reduces bugs
Ensures deadlines are met
Makes your system scalable and maintainable

Start simple, think in blocks, document your design, and always validate your real-time needs.

You can also Visit other tutorials of Embedded Prep

Special thanks to @mr-raj for contributing to this article on EmbeddedPr

May 4, 2025

Master Git Basics: Clone, Commit, Push, Pull (2026)
Git Basics : In this blog post, we will dive deep into the core concepts of Git, one of the most widely used version control systems in modern software development. Whether you’re a beginner or looking to brush up on Git, this guide will help you understand how to efficiently manage and track your codebase.

We’ll start by covering the Git Basics such as cloning repositories, committing changes, pushing and pulling updates, and how these foundational commands are used in everyday development. After that, we’ll explore the power of Branching and Merging, which enables parallel development on separate features or fixes without disrupting the main codebase.

Next, we will dive into Git Workflow and examine popular strategies like Feature Branch Workflow and Git Flow, and explore the commands necessary to follow these workflows effectively. We’ll also tackle Conflict Resolution — a common challenge when collaborating with others — and provide best practices for resolving merge conflicts.

Furthermore, we will compare Git Rebase vs Merge, and understand their differences, use cases, and impact on project history. Finally, we will wrap up with Git Tags and Releases, showing how to mark specific points in your project’s history, such as version releases, and how to manage them with tags.

By the end of this post, you’ll have a solid understanding of Git’s key features and commands, enabling you to collaborate smoothly in any software development project.

1. Git Basics Overview:

Git is a distributed version control system that helps developers manage and track changes to their codebase over time. It allows multiple users to collaborate on the same project without overwriting each other’s changes. Below are the basic Git commands that are commonly used in any development project.
- Clone:
  git clone is used to create a local copy of a remote repository. This command pulls down all the files, commit history, and branches from the remote repository to your local machine. git clone <repository_url> Example: git clone https://github.com/user/project.git
- Commit:
  A commit represents a snapshot of your changes. After modifying files in your working directory, you need to add them to staging and commit them to the local repository.
  - Stage files: git add <file> adds specific files to the staging area. To add all changed files, use git add .. git add .
  - Commit changes: Once your files are staged, you use the git commit command to save your changes to the local repository. git commit -m "Commit message describing changes"
- Push:
  The git push command is used to upload local repository content to a remote repository. It is typically used after committing changes locally to push them to a shared remote repository. git push origin <branch_name> Example: git push origin main
- Pull:
  git pull is used to fetch and integrate changes from the remote repository into your local branch. This command combines git fetch and git merge, ensuring you have the latest changes from the remote branch. git pull origin <branch_name> Example: git pull origin main
Branching & Merging

2. Branching:

Branching allows you to create separate environments to work on different features or fixes without affecting the main codebase. Each branch can be developed independently and then merged back into the main branch.
- Create a branch:
  You can create a new branch with the git branch command. git branch <branch_name> Example: git branch feature/new-feature
- Switch to a branch:
  To start working on a branch, use git checkout to switch to it. git checkout <branch_name> Example: git checkout feature/new-feature Alternatively, you can combine both creating and switching with: git checkout -b <branch_name> Example: git checkout -b feature/new-feature
3. Merging:

Merging is the process of bringing together changes from different branches. Typically, changes from a feature branch are merged back into the main branch.
- Merge a branch:
  First, ensure you’re on the branch that you want to merge into (typically main or master), then use the git merge command. git merge <branch_name> Example: git merge feature/new-feature
Git Workflow (Feature Branch, Git Flow) and All Commands

4. Git Workflow:

Git workflow refers to how developers manage their branches and commits within a repository. Two popular workflows are the Feature Branch workflow and Git Flow workflow.
- Feature Branch Workflow:
  In this workflow, each new feature or bug fix is developed in a separate branch. When the feature is complete, it’s merged into the main branch. Steps:
  1. Create a feature branch: git checkout -b feature/awesome-feature
  2. Commit changes: git add . git commit -m "Add awesome feature"
  3. Push feature branch: git push origin feature/awesome-feature
  4. Open a pull request (PR) and merge into the main branch.
- Git Flow:
  Git Flow is a more structured branching model, often used in larger projects. It divides work into different branches for features, releases, and hotfixes.
  - Main branches:
    main (or master): Production-ready code.
    develop: Ongoing development code, where new features are integrated.
  - Supporting branches:
    Feature branches: Used for new features.
    Release branches: Prepare for production releases.
    Hotfix branches: Used to fix urgent issues in production.
  Git Flow commands:
  Install git-flow: brew install git-flow Initialize git flow in a repository: git flow init Start a feature: git flow feature start <feature_name> Finish a feature: git flow feature finish <feature_name> Start a release: git flow release start <release_version> Finish a release: git flow release finish <release_version> Start a hotfix: git flow hotfix start <hotfix_version> Finish a hotfix: git flow hotfix finish <hotfix_version>
💛 Support Embedded Prep

If you find our tutorials helpful and want to support our mission of sharing high-quality embedded system knowledge, you can contribute by buying us a coffee. Every small contribution helps us keep creating valuable content for learners like you. ☕

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

Conflict Resolution

5. Conflict Resolution:

When merging branches, you might encounter conflicts if two branches modify the same part of a file. Git cannot automatically decide which change should be kept, so it marks the conflict in the file.
- Resolve Conflicts:
  When a conflict occurs, Git will mark the file with conflict markers. Open the conflicted file, look for the markers (e.g., <<<<<<<, =======, >>>>>>>), and manually resolve the conflict by selecting or merging the appropriate changes.
- After resolving conflicts:
  Once you’ve resolved the conflict, stage the file and commit the merge. git add <conflicted_file> git commit
Git Rebase vs Merge

6. Git Rebase vs Merge:
- Merge:
  When you use git merge, you combine the histories of two branches into a single branch. A merge commit is created to maintain the history of both branches.
  - Pros: Maintains a full history of commits, which can be useful for tracking changes.
  - Cons: The history can become messy with multiple merge commits.
  git merge <branch_name>
- Rebase:
  git rebase moves or “replays” your commits from one branch onto another. It results in a cleaner history without merge commits.
  - Pros: Creates a linear history.
  - Cons: Can rewrite history, which might be problematic for shared branches.
  git rebase <branch_name>
Git Tags and Releases

7. Git Tags and Releases:

Git tags are used to mark specific points in history, often used for releases. A tag points to a particular commit, allowing you to easily identify and reference a release.
- Create a tag:
  Tags are typically created at significant points in a project’s development, like when releasing a version. git tag -a <tag_name> -m "Tag message" Example: git tag -a v1.0 -m "First official release"
- Push tags:
  By default, tags are not pushed to remote repositories. You need to explicitly push tags. git push origin <tag_name> Example: git push origin v1.0
- List tags:
  To view all the tags in a repository: git tag
- Checkout a tag:
  To checkout a specific tag (e.g., a previous release): git checkout <tag_name> Example: git checkout v1.0
Releases:
Releases in GitHub or GitLab use tags to provide a versioned snapshot of the code. When creating a release, you can associate it with a tag to specify the version being released.

Step 1: Set up a Remote Repository

To start, we’ll assume there’s a Git repository already hosted on a platform like GitHub or GitLab (you can create one there if needed).

For this example, the URL for the remote repository is:
```
https://github.com/username/SampleProject.git
```
Step 2: Clone the Repository

First, we’ll clone the remote repository to create a local copy.
```
git clone https://github.com/username/SampleProject.git
```
After this, a new folder SampleProject will be created, and it will contain the files from the remote repository.

Step 3: Create a New Branch for Feature Development

Now that we have the repository, let’s create a new branch to work on a new feature. We’ll call this branch feature/add-new-feature.
```
cd SampleProject
git checkout -b feature/add-new-feature
```
The -b flag creates and checks out the new branch.

Step 4: Modify Files and Commit Changes

Let’s assume we add a new file or modify an existing one. For this example, we’ll modify a file called README.md.
1. Open README.md and add a line like: This is a new feature added to the project.
2. After saving the file, we need to stage the changes and commit them.
```
git add README.md  # Stage the file
git commit -m "Add new feature description to README"
```
This command stages the changes and commits them with a descriptive message.

Step 5: Push the Branch to Remote Repository

Now that the feature is ready, let’s push the feature/add-new-feature branch to the remote repository.
```
git push origin feature/add-new-feature
```
This uploads your local branch to the remote repository, making it available for collaboration or review (such as in a pull request).

Step 6: Create a Pull Request (Optional)

If you’re working with a team, you would now go to the remote Git hosting platform (e.g., GitHub) and create a Pull Request (PR) to merge feature/add-new-feature into the main branch.

Step 7: Pull Latest Changes from the Remote Repository

While working on your feature, others may have pushed changes to the remote repository. To keep your local repository up to date, you can pull the latest changes from the main branch.
```
git checkout main        # Switch to the main branch
git pull origin main      # Pull latest changes from remote main branch
```
Step 8: Merge the Feature Branch into Main

Once the feature is approved (e.g., through a PR review), you can merge it back into the main branch. If you have already completed the PR, you’d merge the branches from the Git hosting platform interface. However, let’s do it manually on the command line:
```
git checkout main                  # Switch to the main branch
git merge feature/add-new-feature   # Merge feature branch into main
```
At this point, your main branch includes the changes from feature/add-new-feature.

Step 9: Resolve Merge Conflicts (If Any)

If changes in the main branch and feature/add-new-feature branch conflict (e.g., both modified the same line in README.md), Git will mark the file as conflicted, and you’ll need to resolve the conflict.

You’ll see conflict markers in the file, like:
```
<<<<<<< HEAD
This is the content from the main branch.
=======
This is the content from the feature branch.
>>>>>>> feature/add-new-feature
```
You manually edit the file to keep the desired changes and remove the markers.

After resolving conflicts, stage the changes:
```
git add README.md
git commit -m "Resolve merge conflict"
```
Step 10: Push the Merged Changes to the Remote Repository

After successfully merging the feature branch into the main branch and resolving any conflicts, push the changes back to the remote repository.
```
git push origin main
```
Step 11: Delete the Feature Branch (Optional)

Once the feature is successfully merged, you can delete the local and remote feature branch to keep the repository clean.
- Delete the local branch:
```
git branch -d feature/add-new-feature
```
- Delete the remote branch:
```
git push origin --delete feature/add-new-feature
```
Step 12: Create a Tag for the Release

Once your changes are merged into main and you’re ready to release a version, create a tag.
```
git tag -a v1.0 -m "First release with new feature"
git push origin v1.0
```
This command tags the current commit as v1.0 and pushes the tag to the remote repository.

Summary of Git Commands Used:
- Clone: git clone <repo_url>
- Create Branch: git checkout -b <branch_name>
- Commit Changes: git commit -m "<message>"
- Push Changes: git push origin <branch_name>
- Pull Changes: git pull origin <branch_name>
- Merge Branch: git merge <branch_name>
- Delete Branch: git branch -d <branch_name> (local), git push origin --delete <branch_name> (remote)
- Create Tag: git tag -a <tag_name> -m "<message>"
Git interview questions

Basic Git Interview Questions
1. What is Git and why is it used?
2. What is the difference between Git and GitHub?
3. What is a version control system?
4. What are the advantages of using Git?
5. How do you initialize a Git repository?
6. What does git clone do?
7. What’s the difference between git pull and git fetch?
8. How do you check the status of your repository?
9. How do you stage and commit changes?
10. What does the .gitignore file do?
Intermediate Git Interview Questions
1. What is the difference between git merge and git rebase?
2. How do you resolve merge conflicts?
3. What is a detached HEAD in Git?
4. What are branches in Git and how do you create a new one?
5. What is the purpose of git stash?
6. What is git cherry-pick?
7. How do you undo a commit?
8. Explain git revert, git reset, and git checkout with use cases.
9. How do you delete a branch in Git (local and remote)?
10. What is the use of git tag?
Advanced Git Interview Questions
1. What is the difference between git reset --soft, --mixed, and --hard?
2. How do you handle rebase conflicts?
3. What are Git hooks?
4. What is the reflog in Git?
5. How can you squash commits?
6. How do you recover a deleted branch?
7. Explain the Git workflow you use (e.g., Git Flow, GitHub Flow).
8. What is a fast-forward merge?
9. How do you compare branches?
10. How can you see who changed a line of code (git blame)?
Git in a Team/Real-World Use
1. How do you handle code reviews using Git?
2. How do you handle large binary files in Git?
3. What strategies do you follow to avoid conflicts in team collaboration?
4. How do you deploy code using Git?
5. What are some best practices when using Git in a team environment?
You can also Visit other tutorials of Embedded Prep
Special thanks to @mr-raj for contributing to this article on EmbeddedPr
May 4, 2025

GDB GNU Debugger | Master Beginner-Friendly Guide (2026)

GDB GNU Debugger : GDB is a powerful tool used by developers to inspect what’s going on inside a running program or after it crashes. It helps you find and fix bugs by allowing you to pause execution, examine variables, inspect memory, and even step through lines of code.

The GNU Debugger (GDB) is a powerful tool used to debug programs written in various programming languages. It lets you inspect and modify memory, control the execution flow, set breakpoints, and much more to analyze and fix issues in your code.

GDB GNU Debugger

1. Installing GDB

In Red Hat Developer Toolset, the GNU Debugger is part of the devtoolset-9-gdb package, and it’s automatically installed along with the toolset. To get started with GDB, follow these installation steps:

If you’re using the devtoolset-9 toolchain, GDB is already included. Here’s how you can install the necessary packages:

$ scl enable devtoolset-9 'gcc -g -o output_file input_file'

This will compile your code with debugging information, making it easier to debug later.

2. Preparing Your Program for Debugging

To compile a C or C++ program with debugging information, use the -g flag with gcc or g++. For example:

For a C program:

$ scl enable devtoolset-9 'gcc -g -o fibonacci fibonacci.c'

For a C++ program:

$ scl enable devtoolset-9 'g++ -g -o output_file input_file'

3. Running GDB

To start debugging your program with GDB, use the following command:

$ scl enable devtoolset-9 'gdb fibonacci'

Once inside GDB, you’ll see a prompt where you can start debugging your program. To exit GDB, simply type:

(gdb) quit

4. Listing Source Code

To view the source code of the program you’re debugging, use the list command in GDB. It will show the first 10 lines of the code. You can also change the number of lines displayed:

(gdb) list
(gdb) set listsize 20  # Show 20 lines instead of 10

5. Setting Breakpoints

A breakpoint is a place where the program will stop, allowing you to inspect the state of your program. You can set a breakpoint at a specific line or function:

(gdb) break file_name:line_number
(gdb) break function_name

For example, to set a breakpoint at line 10:

(gdb) break 10

You can list all breakpoints with:

(gdb) info breakpoints

To remove a breakpoint:

(gdb) clear line_number

6. Running Your Program in GDB

Once you’ve set breakpoints, you can run your program inside GDB:

(gdb) run

If your program needs arguments, you can pass them like this:

(gdb) run arg1 arg2

The program will stop at the first breakpoint or when it encounters an error.

7. Displaying Variable Values

To check the current value of a variable while debugging, use the print command:

(gdb) print variable_name

For example, after stopping at a breakpoint, you can print the value of a variable:

(gdb) print a
(gdb) print b

8. Continuing Execution

To continue the program after hitting a breakpoint, use the continue command:

(gdb) continue

If you want to skip a certain number of breakpoints or stop after a few lines of code, use:

(gdb) continue number
(gdb) step number

The step command allows you to execute a specific number of lines, which is useful when you’re debugging loops or functions.

Example Workflow

Compile the Program with Debug Info: $ scl enable devtoolset-9 'gcc -g -o fibonacci fibonacci.c'
Start Debugging with GDB: $ scl enable devtoolset-9 'gdb fibonacci'
Set Breakpoint at Line 10: (gdb) break 10
Run the Program: (gdb) run
Print Variable Values: (gdb) print a (gdb) print b
Continue Execution: (gdb) continue

Let’s work with a simple C code example to demonstrate the use of GDB.

Example C Program: `factorial.c`

#include <stdio.h>

int factorial(int n) {
    if (n == 0 || n == 1) {
        return 1;
    }
    return n * factorial(n - 1);
}

int main() {
    int num = 5;
    int result = factorial(num);
    printf("Factorial of %d is %d\n", num, result);
    return 0;
}

This program calculates the factorial of 5 and prints the result.

Steps to Debug Using GDB:

Compile the Program with Debug Information

To compile the C code with debugging symbols, we use the -g option in gcc.

gcc -g -o factorial factorial.c

This will produce an executable file named factorial.

Start GDB

To start GDB with the compiled program, use the following command:

gdb ./factorial

Set Breakpoints

We want to set a breakpoint at the factorial function to see the recursive calls.

To set a breakpoint at the factorial function, run the following in the GDB prompt:

(gdb) break factorial

Run the Program

Now, run the program inside GDB:

(gdb) run

The program will start, and GDB will pause at the first call to factorial.

Step Through the Code

To step through the code one line at a time, use the step command:

(gdb) step

This will take you inside the factorial function, and you can continue stepping through the function’s execution.

Display Variable Values

To check the value of the variables, such as n, you can use the print command. For example:

(gdb) print n

This will show the value of n at each step of the recursion.

Continue Execution

After reaching the breakpoint and checking variable values, you can continue execution until the next breakpoint (or the end of the program):

(gdb) continue

Exit GDB

Once you’re done, exit GDB by typing:

(gdb) quit

Expected Output

During the debugging session, GDB will allow you to inspect the recursive calls to factorial and the values of n at each step. Eventually, it will display the final result after the program reaches the print statement.

1. GDB Basics and Commands

What is GDB?

GDB is the GNU Debugger. It lets you:

Start your program and pause it anywhere.
View variable values at runtime.
Step through code line by line.
Set breakpoints (pause points).
Inspect memory and CPU registers.

How to Compile with Debug Info

Before using GDB, compile your code with debug symbols:

gcc -g main.c -o main

The -g flag tells the compiler to include debug information.

Starting GDB

gdb ./main

Common Commands

Command	Description
`run`	Starts the program
`break <line/function>`	Sets a breakpoint
`next` or `n`	Steps to next line (skips function calls)
`step` or `s`	Steps into a function
`continue` or `c`	Resumes execution
`print <var>`	Prints the value of a variable
`list`	Shows source code
`quit`	Exits GDB

2. Remote Debugging with GDB

Remote debugging is used to debug a program running on another system (like embedded Linux or RTOS).

Setup

On Target (with GDB server):

gdbserver :1234 ./app

On Host (your PC):

gdb ./app
(gdb) target remote <target-ip>:1234

Now you’re controlling the target program from your host machine.

3. Breakpoints, Watchpoints, Backtrace

Breakpoints

Stop execution at specific lines or functions:

(gdb) break main
(gdb) break 42  # line 42

Watchpoints

Automatically pause when a variable changes:

(gdb) watch counter

Backtrace

See the function call history (call stack):

(gdb) backtrace

This shows which functions were called and in what order.

4. Disassembly and Register Inspection

Disassemble Code

See the machine code for your program:

(gdb) disassemble main

View Registers

See CPU register values (great for low-level debugging):

(gdb) info registers

For ARM/MIPS/other architectures, you’ll see general-purpose and special registers.

5. Debugging on Bare-Metal & RTOS

Bare-Metal Debugging

Bare-metal means there’s no OS — you’re debugging directly on hardware (e.g., ARM Cortex-M microcontroller).

You’ll use:

A cross-compiler (arm-none-eabi-gcc)
gdb for that architecture
An OpenOCD or J-Link GDB server

arm-none-eabi-gdb main.elf
(gdb) target remote :3333
(gdb) load  # Load program onto hardware
(gdb) monitor reset init

RTOS Debugging (e.g., FreeRTOS)

RTOS debugging is similar to bare-metal, but you may need:

RTOS-aware GDB scripts (for thread/task context)
Special memory maps

You can:

Pause execution
View current tasks
Inspect stack of each thread

GDB extensions/plugins like FreeRTOS-aware GDB scripts can show tasks and queues.

How GDB Interacts with Compiled Binaries

GDB (GNU Debugger) is a tool used to examine and control programs after they are compiled. When you compile a program, the compiler turns your human-readable source code into machine-readable binary code. GDB interacts with these compiled binaries by reading and controlling their execution.

Here’s how it works step-by-step:

Reading the Binary File
GDB loads the compiled binary file (usually an executable) into memory. If the binary contains debugging information (generated using the -g flag during compilation), GDB can use this information to map machine code back to your original source code, including variables, functions, and line numbers.
Connecting to the Process
GDB can either start a program directly or attach to an already running process. It uses system-level APIs to take control of the process execution.
Controlling Execution
Once attached, GDB can pause program execution (breakpoints), step through code line-by-line (step/next), or continue execution. This allows programmers to inspect exactly how their code is running.
Inspecting Memory and Variables
GDB reads the memory and register states of the running program. This lets you examine variable values, memory contents, and CPU registers to understand the program’s behavior.
Modifying Execution
GDB can also change variable values, set new program counter positions, or modify registers while the program runs. This helps in testing fixes without recompiling.

Key takeaway: GDB bridges the gap between your compiled binary and the original source code, allowing you to inspect, control, and debug the program’s execution at a very deep level.

Breakpoints and Watchpoints in GDB

When debugging with GDB, you often need to pause the program or observe certain events to understand its behavior. That’s where breakpoints and watchpoints come in. They are both tools to stop or monitor a program during execution, but they work differently.

1. Breakpoints

A breakpoint is a marker you set at a specific line of code or function. When the program execution reaches that point, GDB pauses the program so you can inspect the state of the program.

Example use case:
If your program crashes in a function, you can set a breakpoint at the function start to see exactly what happens before the crash.

How to set a breakpoint in GDB:

(gdb) break main   # Break at the start of main()
(gdb) break 25     # Break at line 25 in the current file

When the program hits the breakpoint, GDB stops execution and gives control back to you.

2. Watchpoints

A watchpoint is like a dynamic watch on a variable or memory location. GDB pauses execution whenever the value of that variable or memory changes.

Example use case:
If a variable is changing unexpectedly, you can set a watchpoint on it to find the exact point where the change happens.

How to set a watchpoint in GDB:

(gdb) watch x   # Watch variable x

When the watched variable changes, GDB stops execution and shows where the change occurred.

Key Differences Between Breakpoints and Watchpoints

Feature	Breakpoint	Watchpoint
Purpose	Stop execution at a specific line or function	Stop execution when a variable or memory changes
Trigger	Reaching a specific location in code	Change in the value of a variable or memory
Usage	Used to inspect execution flow	Used to monitor specific variable changes
Performance	Low impact on performance	Higher performance cost because memory is monitored

In short:

Breakpoints → Stop at a specific point in code.
Watchpoints → Stop when data changes.

Summary

Feature	GDB Command
Set Breakpoint	`break <line/function>`
Step Through Code	`next`, `step`
Inspect Variable	`print var`
Remote Debug	`target remote <ip:port>`
View Registers	`info registers`
Disassemble	`disassemble`
Watch Variable	`watch var`
Backtrace	`backtrace`

Here’s a beginner-friendly, plagiarism-free, and uniquely written explanation of essential GDB commands, complete with simple descriptions and a few helpful tips.

Common GDB Commands You Should Know

Command	What It Does (Beginner-Friendly)
`run` or `r`	Starts the program from the beginning. Great for testing your code cleanly.
`break` or `b`	Puts a stop (breakpoint) at a specific line or function so you can pause there.
`disable`	Temporarily turns off a breakpoint without removing it. Useful for quick toggles.
`enable`	Turns a disabled breakpoint back on. Handy if you’re toggling breakpoints often.
`next` or `n`	Moves to the next line of code without entering into any called function.
`step`	Goes to the next line, but enters into functions to help debug them deeper.
`list` or `l`	Shows the source code around the current line or a specified location.
`print` or `p`	Shows the current value of a variable. Also great for checking expressions.
`quit` or `q`	Exits GDB. You’ll be asked to confirm if the program is still running.
`clear`	Removes all breakpoints, or just one if specified. Good for cleanup.
`continue`	Resumes program execution after hitting a breakpoint or stepping through code.

Example Session (Simple Workflow)

$ gdb ./my_program     # Start GDB with your compiled program
(gdb) break main       # Set a breakpoint at the beginning
(gdb) run              # Start running the program
(gdb) next             # Move to the next line
(gdb) print myVar      # Check the value of a variable
(gdb) continue         # Resume execution until next breakpoint
(gdb) quit             # Exit when you're done

Frequently Asked Questions (FAQ)

1. What is GDB and why is it used?

GDB (GNU Debugger) is a powerful debugging tool used to analyze and debug programs written in languages like C, C++, and others. It helps developers inspect code, find bugs, check variable values, trace program execution, and understand crashes or unexpected behavior.

2. Is GDB only for C/C++ programs?

No! While GDB is widely used for C and C++, it also supports other languages like Ada, Fortran, Go, Rust, and more—depending on compiler support and integration.

3. How do I install GDB?

Linux: Use your package manager (e.g., sudo apt install gdb on Ubuntu).
macOS: Use Homebrew → brew install gdb.
Windows: Install via MinGW or download pre-built binaries from official sites.

4. Can GDB debug running processes?

Yes! GDB can attach to an already running process using the attach <pid> command, allowing you to debug without restarting the application.

5. What are breakpoints in GDB?

Breakpoints are markers you set in code to pause execution at specific lines or functions. They let you inspect program state, variables, and execution flow at precise points.

Example:

(gdb) break main

6. How do I run a program inside GDB?

Use the run command:

(gdb) run

Or pass arguments like:

(gdb) run arg1 arg2

7. What is a backtrace in GDB?

A backtrace (via the bt command) shows the call stack leading to the current point in execution. It’s very helpful for diagnosing where and how a program crashed.

8. Can GDB be used for remote debugging?

Yes. GDB supports remote debugging over serial ports, TCP/IP, or JTAG interfaces. You use target remote to connect to a remote GDB server.

9. Is GDB suitable for beginners?

Absolutely! While it has a learning curve, GDB is beginner-friendly once you grasp basic commands like break, run, next, step, print, and bt.

10. Are there graphical front-ends for GDB?

Yes. Tools like:

DDD (Data Display Debugger)
Eclipse CDT Debugger
Insight
GDB Dashboard (TUI enhancements)

These provide graphical interfaces that make debugging visually easier.

11. How can I debug core dumps with GDB?

If your program crashes and generates a core file, you can inspect it like this:

gdb <program> core

This lets you analyze the state of the program at the time of the crash.

12. Is GDB available for free?

Yes! GDB is completely free and open-source, distributed under the GNU General Public License (GPL).

13. What’s new in GDB for 2025?

(Replace this with your blog’s content if you’ve covered new GDB updates. For example:)

Improved Rust support
Faster multi-thread debugging
Better integration with modern IDEs

14. Where can I learn more about GDB?

Official GDB Manual
Online tutorials
Community forums like Stack Overflow
Your “GDB GNU Debugger | Master Beginner-Friendly Guide (2025)” blog post!

You can also Visit other tutorials of Embedded Prep

Special thanks to @mr-raj for contributing to this article on EmbeddedPrrep

Want to estimate your social media income? Try this Facebook Earning Calculator to calculate potential earnings from Facebook content creators.

May 4, 2025

Master JTAG (Joint Test Action Group): A Beginner-Friendly, In-Depth Guide (2026)

JTAG stands for Joint Test Action Group, which is the name of the group that initially developed the standard. Today, JTAG commonly refers to both the group and the test interface and protocol defined by the IEEE 1149.1 standard.

Originally created in the 1980s, JTAG was developed as a solution to a growing problem in electronics manufacturing: how to test complex circuit boards where physical access to all the pins and components was no longer possible.

Why Was JTAG Created?

As electronic components became smaller and more integrated, traditional testing methods like bed-of-nails testers or external probes couldn’t easily reach the pins or internal signals of components. JTAG was introduced to allow:

Testing of individual pins and board connections,
Debugging of embedded systems,
Programming of microcontrollers, FPGAs, CPLDs, and flash memory,
Diagnosing faults during development and manufacturing.

JTAG Is More Than Just Debugging and Programming

When most people think of JTAG, they associate it with debugging processors or programming FPGAs and CPLDs. That’s not wrong—but it’s only part of the story.

JTAG isn’t just about debugging.
It isn’t just about programming either.

While you might know JTAG through tools that connect to a JTAG interface, such as debuggers or flash programmers, those tools typically use only one part of what JTAG has to offer: the four-wire communication protocol defined by the IEEE 1149.1 standard.

What Else Can JTAG Do?

JTAG was originally developed as a solution for testing circuit boards—specifically to overcome the limitations of traditional test methods like bed-of-nails testers. These older methods required physical access to every pin or needed complex custom setups for functional testing.

To solve this, IEEE created the concept of a Test Access Port (TAP), which uses four signals (TCK, TMS, TDI, TDO) to interact with special test registers inside chips.

The key test register introduced by this standard is the Boundary Scan Register (BSR).

What Is a Boundary Scan Register?

The Boundary Scan Register sits at the edges (or “boundaries”) of a chip, between its functional logic core and the actual pins that connect it to a board. That’s why JTAG testing is often called “boundary scan” testing.

These registers are made up of individual cells that can:

Operate in functional mode, where they don’t interfere with normal chip behavior.
Operate in test mode, where they take control of the chip’s input/output pins.

In test mode, these boundary scan cells allow us to:

Drive specific values onto the board’s signal lines (outputs),
Read the values present on those lines (inputs).

How Does This Help in Testing?

Here’s the powerful part:
When JTAG is used in test mode, it allows engineers to control and observe signals on a PCB without booting the system or loading firmware. The device doesn’t need to be configured—it just needs to support boundary scan.

This means:

You can test for short circuits, opens, and miswirings,
You can run tests without needing full firmware or software,
It reduces the need for physical access to test points.

Two Main Ways to Use JTAG for Testing

Connection Testing
This basic method checks for short circuits and open connections by using only the JTAG-capable devices and their pins. It provides good coverage using the board’s layout and JTAG features.
Extended Testing (with non-JTAG devices)
Tools like XJTAG can go further by using JTAG-enabled chips to talk to non-JTAG devices (e.g., DDR RAM, Flash). This allows testing of more complex components using the existing JTAG infrastructure.

JTAG is much more than a tool for programming chips or debugging firmware. It’s a powerful hardware test interface that helps engineers:

Test boards without physical probes,
Check soldering and connectivity,
Debug hardware issues early in development,
Communicate with various components through a simple 4-pin interface.

So next time you hear “JTAG,” remember:
It’s not just a port—it’s a gateway to deep-level access and testing.

💛 Support Embedded Prep

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

1. Introduction

When working with embedded systems, hardware debugging, or board-level testing, JTAG is a name that comes up often. But what exactly is it?

JTAG stands for Joint Test Action Group—the name of the group that developed the standard. It’s an interface and protocol that allows you to test, debug, and program devices on a circuit board, even when they are soldered down and inaccessible through traditional means.

2. What is JTAG?

At its core, JTAG is a standard for verifying designs and testing printed circuit boards (PCBs) after manufacture. It provides a standardized interface to communicate with chips using just a few pins.

JTAG was standardized as IEEE 1149.1 in 1990 and is commonly used in embedded systems, FPGA programming, microcontroller debugging, and boundary scan testing.

3. Why Was JTAG Introduced?

Before JTAG, engineers used bed-of-nails testers or manually probed signals on PCBs. These methods had major drawbacks:

Couldn’t access densely packed surface-mount devices (SMDs)
Fragile and expensive test fixtures
Not scalable for complex boards

JTAG solved this by embedding test logic inside chips, allowing for internal signal monitoring and control through a serial interface—no need to physically touch internal nodes!

4. How Does JTAG Work?

JTAG enables access to a device’s internal functions using a serial protocol and a Test Access Port (TAP). This port can:

Control internal registers
Access memory
Perform boundary scans
Program flash memory

The TAP connects to a chain of devices called a JTAG daisy chain. Devices in the chain share the same control signals, but each has its own data path.

The core components inside a JTAG-enabled device include:

TAP Controller – Controls the JTAG state machine
Instruction Register (IR) – Decides what operation to perform (e.g., read ID, boundary scan)
Data Registers (DR) – Used to shift in/out data

5. JTAG Pinout and Signals

JTAG usually uses 4 or 5 pins:

Pin Name	Full Form	Description
TDI	Test Data In	Serial data input into the JTAG chain
TDO	Test Data Out	Serial data output from the JTAG chain
TCK	Test Clock	Provides the clock for synchronizing data
TMS	Test Mode Select	Controls the state of the TAP controller
TRST	Test Reset (optional)	Resets the JTAG state machine (not always used)

6. Common Use Cases of JTAG

Boundary Scan Testing
- Check connectivity between pins and trace faults without physical probing.
In-System Programming (ISP)
- Program flash memory, FPGAs, CPLDs, and MCUs via JTAG.
Debugging Embedded Systems
- Set breakpoints, inspect registers, view memory, and single-step through code.
Hardware Bring-Up
- Access low-level hardware registers before firmware is ready.

7. JTAG in Embedded Systems

JTAG is essential for developers working on ARM Cortex, STM32, ESP32, or custom SoCs. It allows you to:

Flash firmware without bootloader
Debug without printf()
Perform post-silicon validation

Example: JTAG with STM32

Using an ST-Link or J-Link programmer, you can connect to the STM32 via JTAG or SWD (Serial Wire Debug, a 2-wire variant) and debug using tools like OpenOCD + GDB or STM32CubeIDE.

8. Tools and Software for JTAG

Hardware Debug Probes:

SEGGER J-Link
ST-Link (for STM32)
TI XDS110 (for TI MCUs)
FTDI-based cables (DIY options)

Software:

OpenOCD (Open On-Chip Debugger) – Popular open-source JTAG interface
GDB – GNU debugger for step-through debugging
Vendor IDEs – STM32CubeIDE, IAR, Keil MDK, Code Composer Studio

9. Advantages and Limitations

Advantages

Access internal registers and memory
Non-intrusive testing and debugging
Programming without bootloader
Works even when the system is not fully booted

Limitations

Not supported by all chips
Configuration can be complex for beginners
Risk of bricking if improperly used
JTAG interfaces can be disabled for security in some products

10. Conclusion

JTAG is a powerful and essential interface for hardware debugging, device testing, and embedded system development. While it may seem complex at first, learning JTAG opens the door to low-level system access, deep debugging, and smoother hardware bring-up processes.

If you’re working with microcontrollers, FPGAs, or custom PCBs, understanding JTAG is a must-have skill.

FAQ – Master JTAG (Joint Test Action Group): A Beginner-Friendly, In-Depth Guide (2025)

1. What is JTAG and why should I learn it?

JTAG (Joint Test Action Group) is a standard (IEEE 1149.1) used for testing, programming, and debugging hardware—mainly microcontrollers, FPGAs, and CPUs. Learning JTAG is essential for embedded developers, hardware engineers, and system testers as it gives direct access to chip internals, enabling tasks like:

Boundary-scan testing (fault detection on PCBs)
Flashing firmware directly
Debugging software running on target boards

2. What are the typical use cases of JTAG?

Hardware testing: Identify faulty components or soldering defects.
Firmware flashing: Load firmware into non-volatile memory without a bootloader.
Real-time debugging: Step through code, inspect registers, memory, and control execution.
Board bring-up: Debug and validate hardware during prototype development.

3. Which hardware tools do I need for JTAG?

You typically need:

A JTAG debugger/programmer (e.g., SEGGER J-Link, ST-LINK, OpenOCD-compatible dongles)
A target device that supports JTAG (e.g., STM32, ARM Cortex-M, Xilinx FPGAs)
A JTAG connector (e.g., 10-pin, 20-pin headers)
JTAG-compatible software tools (OpenOCD, GDB, manufacturer-specific IDEs)

4. What are the standard JTAG pinouts and signals?

Typical JTAG signals include:

TDI (Test Data In) – Data input to the target
TDO (Test Data Out) – Data output from the target
TCK (Test Clock) – Clock signal
TMS (Test Mode Select) – Controls state transitions
TRST (optional) – Test Reset
GND – Ground
Vref – Reference voltage (for logic level compatibility)

5. How does JTAG work internally?

JTAG uses a TAP controller (Test Access Port), which moves through states based on the TMS and TCK lines. It shifts data into registers (e.g., instruction register, data register) and enables control over internal signals without requiring CPU code execution.

6. Is JTAG only for testing hardware?

No. While JTAG was initially designed for boundary-scan testing, it evolved to support:

Flash programming
Low-level debugging
Chip-level introspection
Reset and boot control

7. Can I use JTAG with open-source tools?

Yes. Tools like:

OpenOCD (Open On-Chip Debugger) for programming and debugging
GDB for source-level debugging with breakpoints and watchpoints
UrJTAG for boundary-scan and low-level testing

These tools are often free and widely supported.

8. What’s the difference between JTAG and SWD (Serial Wire Debug)?

JTAG: 4–5 signals; full IEEE 1149.1 standard; widely supported.
SWD: ARM-specific 2-wire protocol; lighter and faster; used on Cortex-M devices.
Both support debugging and programming, but SWD is preferred for space-constrained designs.

9. What are boundary-scan and chain configurations in JTAG?

Boundary-scan: Allows testing of I/O pins without booting the processor.

JTAG chain: Multiple devices can be connected in series (TDI → TDO) using a single JTAG interface. Each device has a unique ID and is accessed through a specific instruction.

10. What are common JTAG errors and how do I fix them?

Error	Cause	Fix
Target not found	Wrong pinout, bad solder	Check wiring, use multimeter
Device ID mismatch	Wrong chip selected	Check chain or update config
No response to TCK/TMS	Dead chip or damaged port	Try alternate device or port
OpenOCD config failed	Wrong interface/chip	Double-check .cfg files

11. Can JTAG be used on production devices?

Yes, but JTAG is often disabled or locked for security reasons in production devices. Secure provisioning may require unlocking or access keys.

12. Where can I practice JTAG debugging hands-on?

Start with:

STM32 Nucleo or Discovery boards
ESP32 DevKit
Raspberry Pi with GPIO for JTAG
FPGAs like Xilinx or Intel (with USB Blaster, Platform Cable)

Use OpenOCD + GDB or manufacturer IDEs (STM32CubeIDE, Xilinx Vivado, etc.).

13. What are the career benefits of learning JTAG?

Mastering JTAG gives you an edge in:

Embedded software development
Board-level diagnostics
Hardware testing and verification
Secure firmware deployment
It’s a key skill for Embedded Engineers, Firmware Developers, and Test Engineers.

You can also Visit other tutorials of Embedded Prep

Special thanks to @mr-raj for contributing to this article on EmbeddedPrep

May 4, 2025

What is SWD Serial Wire Debug? | Master Beginner-Friendly Guide (2026)

SWD Serial Wire Debug : When working with microcontrollers, debugging is a key part of development. One common way to debug embedded systems is using SWD, short for Serial Wire Debug. It’s a modern, efficient way to communicate with a microcontroller during development.

Let’s break it down in a simple way.

What is SWD Serial Wire Debug?

Serial Wire Debug (SWD) is a two-wire protocol developed by ARM for debugging ARM Cortex-M microcontrollers. It is an alternative to the older JTAG protocol, which uses more pins.

SWD allows you to:

Load firmware into the microcontroller.
Set breakpoints and step through code.
Read and write memory.
Monitor and control the processor state.

SWD Serial Wire Debug vs JTAG

Feature	SWD (Serial Wire Debug)	JTAG
Wires	2	4-5
Speed	Fast	Fast
Pin Usage	Low (good for small MCUs)	Higher (more GPIO needed)
Complexity	Simpler	More complex
Debug Access	Full access	Full access

So, SWD is preferred when you have limited pins available and are working with ARM-based chips.

How SWD Serial Wire Debug Works

SWD uses only 2 main signals:

SWDIO – Serial Wire Debug Input/Output
Acts like data line (similar to SDA in I2C).
SWCLK – Serial Wire Clock
Acts like the clock line (similar to SCL in I2C).

Optionally, you might also have:

nRESET – To reset the microcontroller from the debugger (optional).
GND – A common ground between your debug tool and target board (mandatory).

Tools Involved

To use SWD, you need:

A microcontroller that supports SWD (e.g., STM32, NXP, etc.).
A debug probe, such as:
- ST-Link (for STM32)
- J-Link (Segger)
- CMSIS-DAP
A debugger software like:
- STM32CubeIDE
- Keil uVision
- OpenOCD with GDB

SWD Serial Wire Debug Pinout Example (STM32)

Here’s a common SWD pinout on STM32 boards:

Pin Name	Function
SWDIO	Data
SWCLK	Clock
GND	Ground
3.3V	Power supply
NRST	Reset (optional)

Why Use SWD?

👨‍💻 Easy Debugging: Load, step, break, and inspect code easily.
🧠 Access RAM/Flash: Read/write memory and registers.
🔄 Flash Programming: Upload firmware via the debug interface.
📉 Fewer Pins: Perfect for space-constrained designs.
🧰 Low-Cost Tools: Many low-cost debug probes available.

Real-Life Use Case

Let’s say you’re working with an STM32 microcontroller. You want to flash your code and debug it:

Connect ST-Link to SWDIO, SWCLK, GND, and optionally NRST.
Open STM32CubeIDE and start a debug session.
You can now:
- Set breakpoints in code.
- See variables change in real time.
- Step through the program.

Prerequisites

Before you start, make sure you have:

✅ A microcontroller board (e.g., STM32F103, STM32 Nucleo).
✅ A debug probe (e.g., ST-Link, J-Link, or CMSIS-DAP).
✅ A PC with debugging software installed (e.g., STM32CubeIDE, Keil uVision, OpenOCD + GDB).
✅ Wires or a USB cable to connect the debugger.
✅ Basic USB driver for the debug probe installed.

💛 Support Embedded Prep

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

Step-by-Step: Connecting SWD

1. Identify SWD Pins on the Microcontroller

Look for the following pins on your MCU or dev board:

SWDIO – Data line
SWCLK – Clock line
GND – Ground
NRST – (Optional, Reset line)
VCC – Target voltage reference (often 3.3V)

You can find these in the datasheet or board pinout diagram.

2. Connect the Debug Probe

Match these pins between the debugger and the target board:

Debugger Pin	Target Board Pin
SWDIO	SWDIO
SWCLK	SWCLK
GND	GND
NRST (opt.)	NRST
VCC (ref.)	3.3V or 5V

Ensure you connect GND properly. Without a common ground, SWD won’t work.

3. Power the Target

Some debug probes (like ST-Link) can provide power.
Or power the board externally via USB or battery.

Step-by-Step: Debugging

4. Open Your IDE or Debug Software

Examples:

STM32CubeIDE for STM32
Keil uVision
VS Code with GDB + OpenOCD
Segger Ozone for J-Link

5. Create or Open a Project

Write or import your embedded C/C++ code.
Make sure the correct MCU is selected.
Configure the debugger settings if needed.

6. Build Your Code

Click Build / Compile.
Ensure the project compiles without errors.

7. Start Debug Session

Click Debug (Bug icon).
Your IDE will flash the firmware to the MCU via SWD.
It will then pause at main() (or wherever you’ve set breakpoints).

8. Debugging Features You Can Use

Once debugging starts, you can:

🔴 Set breakpoints
🔁 Step over/into code
🧠 Watch variables and memory
🛑 Halt/resume the target
🔍 Monitor registers and peripherals

⏹️ 9. Stop Debugging

Click Terminate or Stop Debugging in the IDE.

Summary

Step	Action
1	Identify SWDIO, SWCLK, GND, etc.
2	Connect debug probe to target board
3	Power the board
4	Open IDE and load project
5	Build the code
6	Start debug session
7	Set breakpoints, inspect memory
8	Stop debug session

You can also Visit other tutorials of Embedded Prep

Special thanks to @mr-raj for contributing to this article on EmbeddedPrep

May 4, 2025

Master GCC Command Line Options: A Beginner-Friendly Guide (2026)

GCC Command Line Options : Are you new to GCC and feeling overwhelmed by flags like -O2, .o files, or linker scripts? This beginner-friendly tutorial will guide you step-by-step through the world of GCC — the GNU Compiler Collection. Learn how your code transforms from .c to executable, understand every compilation stage (Preprocessing, Compilation, Assembly, Linking), and get hands-on with cross-compilation, object files, static vs shared libraries, and optimization techniques.

You’ll also explore how to debug effectively using -g, what linker scripts do, and how to use essential toolchain components like as, ld, objdump, nm, and readelf.

Perfect for embedded programmers, systems developers, or any curious C/C++ learner who wants to master the build process from the inside out!

What You’ll Learnin this tutorial of GCC Command Line Options:

GCC Command-Line Options Explained
Compilation Stages (Preprocessing ➝ Linking)
Cross-Compilation Made Easy
Understanding .o, .a, .so Files
Optimization Flags (-O0 to -O3, -Os, -Ofast)
Debugging with -g and GDB
Basics of Linker Scripts
Practical Use of as, ld, objdump, nm, readelf

What is GCC?

GCC is a powerful compiler used to compile programs written in C, C++, and other languages. It’s used on Linux, embedded systems, and more.

Basic Structure of GCC Command:

gcc [options] source_files [object_files] [-o output_file]

✅ Commonly Used GCC Options:

Option	Description
`-o output`	Specify the name of the output file.
`-c`	Compile source to object file (.o) without linking.
`-Wall`	Enable most compiler warnings.
`-Werror`	Treat all warnings as errors.
`-g`	Include debug information.
`-O0` to `-O3`	Control optimization level.
`-E`	Stop after preprocessing.
`-S`	Stop after compilation (output assembly).
`-v`	Verbose output showing stages and toolchain paths.
`-I<dir>`	Add directory to header file search path.
`-L<dir>`	Add directory to library search path.
`-l<lib>`	Link with specified library (e.g., `-lm` for math).

Example 1: Compile a C file

gcc hello.c -o hello

Example 2: Compile with warnings and debug info

gcc -Wall -g hello.c -o hello

Example 3: Stop after creating object file

gcc -c hello.c

This creates hello.o which can be linked later.

When to Use What:

Goal	Flags to Use
Debugging	`-g -O0`
Performance	`-O2` or `-O3`
Library building	`-c`, `-fPIC`, `-shared`
Troubleshooting warnings	`-Wall -Werror`

Perfect! Let’s move on to:

GCC Compilation Stages (Preprocessing, Compilation, Assembly, Linking)

GCC doesn’t just “compile” your code in one step—it goes through 4 main stages:

Overview of Stages

Stage	Command Flag	Description
1. Preprocessing	`-E`	Handles macros, `#include`, `#define`, removes comments
2. Compilation	`-S`	Converts preprocessed code to Assembly
3. Assembly	`-c`	Converts Assembly to Object code (.o)
4. Linking	(default)	Combines object code and libraries into final binary

1. Preprocessing (`-E`)

What Happens:

Expands #include headers
Replaces #define macros
Removes comments

Example:

gcc -E hello.c -o hello.i

Output: hello.i (pure C code with macros expanded)

2. Compilation (`-S`)

What Happens:

Converts .i to assembly (.s)
Handles syntax checking and optimizations

Example:

gcc -S hello.i -o hello.s

Output: hello.s (human-readable assembly code)

3. Assembly (`-c`)

What Happens:

Converts .s to machine code (.o)
Done by as (assembler)

Example:

gcc -c hello.s -o hello.o

Output: hello.o (object file, not runnable yet)

4. Linking (Default GCC behavior)

What Happens:

Links .o files and libraries to create final executable
Done by ld (linker)

Example:

gcc hello.o -o hello

Output: hello (final executable)

Full Manual Process:

gcc -E hello.c -o hello.i
gcc -S hello.i -o hello.s
gcc -c hello.s -o hello.o
gcc hello.o -o hello

Quick Tip:

To see all stages and tools used by GCC:

gcc -v hello.c -o hello

Cross Compilation

What is Cross Compilation?

Cross compilation is when you compile code on one system (host) but the output is meant to run on a different system (target), often with a different CPU architecture (e.g., x86 host → ARM target).

Why Use Cross Compilation?

Building for embedded systems (e.g., ARM Cortex on Raspberry Pi, ESP32)
Developing for devices with limited resources
Compiling code for different operating systems (Linux → QNX, Windows → Linux)

Common Cross Compilation Toolchain

Tool	Purpose
`arm-none-eabi-gcc`	GCC for bare-metal ARM targets
`arm-linux-gnueabihf-gcc`	GCC for Linux ARM hard-float ABI targets
`aarch64-linux-gnu-gcc`	GCC for 64-bit ARM Linux targets
`x86_64-w64-mingw32-gcc`	GCC for compiling Windows binaries from Linux

Structure of a Cross-Compiler:

<target>-<tool>

Example:

arm-linux-gnueabihf-gcc = cross-compiler for ARM Linux hard-float

Cross Compilation Example:

Let’s say you have this simple C file: `main.c`

#include <stdio.h>
int main() {
    printf("Hello from ARM!\n");
    return 0;
}

Compile for ARM Linux:

arm-linux-gnueabihf-gcc main.c -o main_arm

Result:

Output binary main_arm runs on ARM target (e.g., Raspberry Pi)
It will not run on your x86 machine

💛 Support Embedded Prep

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

How to Check Binary Architecture:

file main_arm

Example Output:

main_arm: ELF 32-bit LSB executable, ARM, EABI5, dynamically linked...

Installing Cross Compilers:

On Ubuntu/Debian:

sudo apt-get install gcc-arm-linux-gnueabihf

For bare-metal (no OS):

sudo apt-get install gcc-arm-none-eabi

Checklist for Successful Cross Compilation:

Correct cross-compiler installed
Use proper --sysroot or -I, -L paths if targeting a full OS
Link against target-specific libraries
Test the binary on the target device

GCC Optimization Flags: `-O0`, `-O1`, `-O2`, `-O3`, `-Os`, `-Ofast`

GCC offers optimization flags to control how much it tweaks your code to make it faster, smaller, or more efficient.

🔧 These optimizations are applied during the compilation stage (.c → .s).

Why Use Optimization?

Improve performance (speed)
Reduce code size
Enable inlining, loop unrolling, dead code removal, etc.

Optimization Levels

Flag	Description
`-O0`	🔴 No optimization (default in debug mode). Easier to debug.
`-O1`	🟡 Basic optimization, removes unused code.
`-O2`	🟢 Aggressive optimization, safe for most applications.
`-O3`	🔵 Maximum performance. Includes `-O2` + inlining & loop unrolling.
`-Os`	⚪ Optimize for size, not speed.
`-Ofast`	🚨 Fastest possible, but unsafe: ignores standards (e.g., IEEE/strict aliasing rules)

Example:

gcc -O0 main.c -o main_O0
gcc -O2 main.c -o main_O2
gcc -O3 main.c -o main_O3
gcc -Os main.c -o main_Os

Use time ./main_Ox or size main_Ox to compare runtime and binary size.

Inspect Optimized Code:

gcc -S -O3 main.c -o main_O3.s

This outputs assembly code so you can see how optimization changes instructions.

Pro Tip:

Use optimization with debugging (covered next):

gcc -g -O2 main.c -o main

This allows debugging even with optimized code, although some variables might be removed or reordered.

Great! Let’s now cover:

Debug Flags & Symbols: `-g`, `-O0` to `-O3`

When developing software, debugging is crucial. GCC provides flags to include debug symbols and control optimization levels that affect debugging behavior.

`-g`: Add Debug Info

Embeds debugging symbols (like variable names, function names, source lines) into the binary.
These symbols are used by GDB or other debuggers.
Doesn’t affect performance or behavior at runtime.

Example:

gcc -g main.c -o main

Now you can debug with:

gdb ./main

Optimization & Debugging

Flag combo	Use case
`-g -O0` (default)	Easiest debugging: variables, breakpoints work as expected
`-g -O2` or `-g -O3`	Debug optimized code: might skip or inline functions, remove variables
`-O2` only	No debug info, faster execution
`-g` only	Debug symbols, but no optimization

Test Code:

#include <stdio.h>
int main() {
    int x = 42;
    printf("x = %d\n", x);
    return 0;
}

Compile and debug:

gcc -g -O0 main.c -o debuggable
gdb ./debuggable

Inside GDB:

(gdb) break main
(gdb) run
(gdb) print x

If you compile with -O2 or -O3, x may be optimized away:

gcc -g -O2 main.c -o optimized_debug

Inside GDB:

(gdb) print x

May return “optimized out”.

Common Debug Tools:

Tool	Purpose
`gdb`	Debugger for stepping through code
`valgrind`	Memory leak checker
`strace`	Trace system calls
`ltrace`	Trace library calls

Combine Flags Smartly

✅ Development:

gcc -g -O0 -Wall -o app app.c

✅ Release (optional debug):

gcc -g -O2 -o app app.c

You can also strip symbols before release:

strip app

GCC Toolchain Components

What is a Toolchain?

A toolchain is a set of programming tools used together to build (compile), link, and analyze software — especially in systems programming like C, C++, and embedded development.

Think of it like a production line in a factory: each tool does a specific job to turn your source code into a working executable program.

Basic Steps in a Toolchain:

Preprocessing – handles #include, #define, etc.
Compiling – converts C code into assembly.
Assembling – converts assembly to object code.
Linking – combines object files and libraries into a final executable.

Each of these steps is done by a specific tool.

Common Components in a GCC Toolchain:

Step	Tool	Purpose
Preprocessing	`cpp`	Processes `#include`, macros
Compiling	`gcc` or `cc1`	Turns C/C++ into assembly code
Assembling	`as`	Converts `.s` to `.o`
Linking	`ld`	Combines `.o` files into binary
Debugging	`gdb`	Debugs your program
Analyzing	`objdump`, `nm`, `readelf`	Analyze and inspect binaries

Why Use a Toolchain?

Automates the process of building software.
Helps you go from source code to executable step by step.
Gives you fine control over what happens at each stage.
Essential in cross-compilation (e.g., compiling code on a PC to run on an embedded board like ARM or ESP32).

Real-World Analogy:

Imagine you’re baking a cake:

Recipe (source code) → You follow steps (preprocess, compile, etc.)
Ingredients → Preprocessed and compiled pieces
Oven → The assembler
Icing and decoration → Linker adds libraries and finishes the executable

At the end, you get a ready-to-eat cake, or in our case, a working program!

In this tutorial, we’ll understand 5 key tools:

as — the assembler
ld — the linker
objdump — the binary disassembler
nm — lists symbols
readelf — reads ELF binary structure

1. `as` — The Assembler

What it does:

as converts assembly language (.s) into machine code object files (.o).

Concept:

After the compiler generates assembly code from C/C++ (gcc -S), the assembler takes this .s file and converts it into binary instructions that the CPU can understand.

Example:

gcc -S hello.c     # Step 1: Get assembly code (hello.s)
as hello.s -o hello.o  # Step 2: Assemble to object file

You now have an object file hello.o.

2. `ld` — The Linker

What it does:

ld combines multiple .o files and libraries into a single executable.

Concept:

It resolves symbol references (like function calls), adds startup code, and organizes the layout of memory sections (text, data, etc.).

Example:

ld -o hello hello.o -lc -dynamic-linker /lib64/ld-linux-x86-64.so.2 -e main

Note: Usually, gcc does this linking automatically. The above is a manual link.

3. `objdump` — The Disassembler

What it does:

objdump shows you what’s inside an object or binary file. You can view assembly code, symbol tables, and more.

Concept:

Useful for debugging or reverse engineering. You can see what machine code was generated from your C/C++ code.

Example:

objdump -d hello.o

This disassembles the object file — shows actual assembly instructions.

You can also inspect all:

objdump -x hello.o

4. `nm` — Lists Symbols

What it does:

nm lists symbols (like functions and global variables) from object files or executables.

Concept:

Symbols can be functions, variables, or labels. It shows whether they’re defined, undefined, or global/static.

Example:

nm hello.o

Sample output:

00000000 T main
         U printf

T main: symbol main is defined in text (code) section.
U printf: symbol printf is undefined (from libc).

5. `readelf` — Reads ELF Binaries

What it does:

readelf displays information from ELF (Executable and Linkable Format) files — used by Linux.

Concept:

ELF files are used for executables, object files, shared libs, etc. You can view headers, sections, symbol tables, etc.

Example:

readelf -h hello.o    # ELF header
readelf -S hello.o    # Section headers
readelf -s hello.o    # Symbol table

Summary Table

Tool	Purpose	Example
`as`	Assembles `.s` to `.o`	`as file.s -o file.o`
`ld`	Links `.o` to executable	`ld file.o -o file`
`objdump`	Shows machine code, symbols	`objdump -d file.o`
`nm`	Lists functions/variables	`nm file.o`
`readelf`	Displays ELF internals	`readelf -h file.o`

Try it Yourself: Mini Demo

Create a file:

// hello.c
#include <stdio.h>
void greet() { printf("Hello!\n"); }
int main() { greet(); return 0; }

Compile step by step:

gcc -S hello.c            # Creates hello.s
as hello.s -o hello.o     # Assemble to object file
ld hello.o -o hello -lc -dynamic-linker /lib64/ld-linux-x86-64.so.2 -e main
./hello                   # Run the program

Inspect:

nm hello.o
objdump -d hello.o
readelf -h hello

You can also Visit other tutorials of Embedded Prep

Special thanks to @mr-raj for contributing to this article on EmbeddedPr

May 3, 2025

Master Makefile and CMake | A Beginner’s Guide for Embedded Projects (2026)

Makefile and CMake: A Beginner’s Guide for Embedded Projects

Makefile and CMake : In the world of embedded systems, building and compiling software requires a solid understanding of how to manage dependencies and automate the process. Makefile and CMake are two key tools used for this purpose. Let’s dive into what each of them is and how they are used in embedded projects.

1. What is a Makefile?

A Makefile is a file that contains a set of rules used by the make utility to automatically build and manage dependencies in a project. It defines how to compile and link the application, how the build process works, and how different files interact with each other. Makefiles are particularly useful in embedded systems because they allow developers to efficiently manage the compilation of large projects with multiple files and dependencies.

In embedded systems and low-level software development, automating the build process is essential for productivity and reliability. This article covers:

✅ Makefile Basics
✅ Makefile Variables, Targets, and Rules
✅ Makefile for Embedded Projects
✅ CMake Basics
✅ Writing CMakeLists.txt
✅ CMake vs Make
✅ Cross-compilation with CMake

Makefile Basics

make is a build automation tool that uses a file named Makefile to describe how to compile and link a program. The Makefile contains rules to tell make how to build the targets (like .o or .elf files).

Structure of a Makefile

target: dependencies
    <TAB>command

target: usually the name of the file to generate (like main.o or app.elf)
dependencies: files that must exist or be updated before the target is built
command: shell command to generate the target from the dependencies

Makefile Variables, Targets, and Rules

Variables

Makefiles use variables to simplify and reuse values:

CC = gcc
CFLAGS = -Wall -O2

Use them like this:

$(CC) $(CFLAGS) -o main main.c

Targets and Rules

main: main.o utils.o
    $(CC) -o main main.o utils.o

Example Makefile

CC = gcc
CFLAGS = -Wall -Wextra

all: main

main: main.o utils.o
    $(CC) $(CFLAGS) -o main main.o utils.o

main.o: main.c
    $(CC) $(CFLAGS) -c main.c

utils.o: utils.c
    $(CC) $(CFLAGS) -c utils.c

clean:
    rm -f *.o main

Run make to build and make clean to delete generated files.

Makefile for Embedded Projects

In embedded systems, we use a cross-compiler and build .elf files for a different architecture (e.g., ARM Cortex-M).

Example: Makefile for STM32 with arm-none-eabi-gcc

CC = arm-none-eabi-gcc
CFLAGS = -Wall -mcpu=cortex-m4 -mthumb -O2
LDFLAGS = -Tstm32.ld

OBJS = main.o startup.o

all: firmware.elf

firmware.elf: $(OBJS)
    $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^

%.o: %.c
    $(CC) $(CFLAGS) -c $< -o $@

clean:
    rm -f *.o *.elf

💛 Support Embedded Prep

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

CMake Basics

CMake is a more modern and platform-independent build system generator. It produces Makefiles or project files (e.g., for Visual Studio) from a CMakeLists.txt file.

Why CMake?

Portable across Linux, Windows, macOS
Supports cross-compilation
Easily integrates with IDEs and external libraries

Writing CMakeLists.txt

A simple CMakeLists.txt for a C/C++ project:

cmake_minimum_required(VERSION 3.10)
project(MyProject C)

set(CMAKE_C_STANDARD 99)

add_executable(my_app main.c utils.c)

With Custom Flags

set(CMAKE_C_FLAGS "-Wall -O2")

For Embedded Toolchain

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_C_FLAGS "-mcpu=cortex-m4 -mthumb -Wall")

CMake vs Make

Feature	Make	CMake
Simplicity	Simple and manual	More abstract and modular
Portability	Unix-based mostly	Cross-platform support
Dependency Mgmt	Manual	Automatic with `target_link_libraries()`
IDE Integration	Limited	Easy integration (e.g., CLion, VSCode)
Cross-compilation	Needs effort	Built-in support via toolchains

Cross-compilation with CMake (Beginner Friendly)

To compile code for an embedded board (e.g., ARM), you need a toolchain file.

🧾 Toolchain file: `arm-gcc-toolchain.cmake`

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR cortex-m4)

set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-g++)

set(CMAKE_C_FLAGS "-mcpu=cortex-m4 -mthumb -Wall")

🧪 Building with CMake

mkdir build
cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../arm-gcc-toolchain.cmake
make

Summary

Concept	Use Case
Makefile	Simple, fast build control
Makefile for embedded	Customize for cross-compilation
CMake	Portable, modern build system
CMakeLists.txt	Project setup instructions
CMake vs Make	Choose based on project complexity
Cross-compilation	Use toolchain files with CMake

Mini Project: LED Blinking with Timer on STM32 (or any ARM Cortex-M)

Features:

Uses embedded C
Supports building with Makefile and CMake
Configurable for cross-compilation
Blinks an LED using hardware timer
Easy to test in STM32CubeIDE or real hardware (e.g., STM32F4, STM32F1, or QEMU)

Folder Structure

led-blink/
├── src/
│   ├── main.c
│   └── timer.c
├── inc/
│   └── timer.h
├── Makefile
├── CMakeLists.txt
├── toolchain/
│   └── arm-gcc-toolchain.cmake
└── stm32.ld

1. main.c

#include "timer.h"

int main(void) {
    timer_init();
    while (1) {
        toggle_led();    // toggles GPIO pin
        delay_ms(500);   // delay using timer
    }
}

2. timer.c

#include "timer.h"
#include "stm32f4xx.h" // MCU-specific header

void timer_init() {
    RCC->AHB1ENR |= RCC_AHB1ENR_GPIOAEN;
    GPIOA->MODER |= (1 << (5 * 2));
}

void toggle_led() {
    GPIOA->ODR ^= (1 << 5);
}

void delay_ms(int ms) {
    for (volatile int i = 0; i < ms * 8000; i++);
}

3. timer.h

#ifndef TIMER_H
#define TIMER_H

void timer_init(void);
void toggle_led(void);
void delay_ms(int ms);

#endif

4. Makefile

CC = arm-none-eabi-gcc
CFLAGS = -mcpu=cortex-m4 -mthumb -Wall -O2
LDFLAGS = -Tstm32.ld

SRCS = src/main.c src/timer.c
OBJS = $(SRCS:.c=.o)

INCLUDES = -Iinc

all: led.elf

led.elf: $(OBJS)
	$(CC) $(CFLAGS) $(INCLUDES) -o $@ $^ $(LDFLAGS)

%.o: %.c
	$(CC) $(CFLAGS) $(INCLUDES) -c $< -o $@

clean:
	rm -f src/*.o *.elf

5. CMakeLists.txt

cmake_minimum_required(VERSION 3.10)
project(LED_Blink C)

include_directories(inc)
file(GLOB SOURCES "src/*.c")

add_executable(led.elf ${SOURCES})

set(CMAKE_C_FLAGS "-mcpu=cortex-m4 -mthumb -Wall -O2")
set(CMAKE_EXE_LINKER_FLAGS "-T${CMAKE_SOURCE_DIR}/stm32.ld")

6. toolchain/arm-gcc-toolchain.cmake

set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_SYSTEM_PROCESSOR cortex-m4)

set(CMAKE_C_COMPILER arm-none-eabi-gcc)
set(CMAKE_CXX_COMPILER arm-none-eabi-g++)

set(CMAKE_C_FLAGS "-mcpu=cortex-m4 -mthumb -Wall -O2")

7. stm32.ld (Example Linker Script)

You can use an STM32 linker script from CubeIDE or a sample like:

ENTRY(Reset_Handler)

MEMORY
{
  FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 512K
  RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 128K
}

SECTIONS
{
  .text : {
    KEEP(*(.isr_vector))
    *(.text*)
    *(.rodata*)
  } > FLASH

  .data : {
    *(.data*)
  } > RAM AT > FLASH

  .bss : {
    *(.bss*)
  } > RAM
}

Building Instructions

With Make

make

With CMake (Cross-Compile)

mkdir build
cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=../toolchain/arm-gcc-toolchain.cmake
make

Difference Between Make and CMake

Make and CMake are both tools used for automating the build process, but they serve different purposes and have distinct features. Here’s a detailed comparison:

1. What They Do

Make:
Make is a build automation tool that reads a Makefile, a script that defines rules for compiling and linking a project. It determines how to update files and handles the dependencies between source files, object files, and executables. Make is platform-dependent, and it requires you to manually specify how each file in the project should be compiled and linked.
CMake:
CMake is a build system generator. It generates platform-specific build files (e.g., Makefiles, Visual Studio project files, etc.) from a CMakeLists.txt configuration file. CMake is platform-independent and simplifies the process of generating appropriate build scripts for different systems or toolchains. CMake abstracts the complexity of platform-specific details, allowing you to focus on the project itself rather than how to compile it.

2. Platform Dependency

Make:
Make is typically used on Unix-like systems (Linux, macOS). Although it can be used on Windows with tools like MinGW, it’s less flexible in cross-platform environments.
CMake:
CMake is cross-platform by design. It can generate build files for different platforms (Linux, Windows, macOS, and embedded systems) and for different build systems (e.g., Make, Ninja, Visual Studio). This makes CMake more versatile for larger projects that need to run on multiple platforms.

3. Configuration

Make:
In Make, the configuration is done directly in the Makefile. The Makefile contains instructions about how to build the project, including which compiler to use, flags, dependencies, and rules. You have to write all these rules manually.
CMake:
In CMake, the configuration is done in the CMakeLists.txt file. This file is platform-independent, and CMake will use it to generate the appropriate build files for the target platform and build system. You don’t have to worry about platform-specific details in the configuration file.

4. Cross-Platform Support

Make:
Makefiles are often written for a specific platform. For example, a Makefile might be written for Linux using gcc and g++. While Make can be used on other platforms (e.g., Windows with MinGW), it’s not as flexible or automatic in handling different platforms or toolchains.
CMake:
CMake handles cross-platform development out of the box. By using CMake, you can generate Makefiles for Linux, Visual Studio projects for Windows, and Xcode projects for macOS from the same set of source files. You can also configure CMake to handle cross-compilation for embedded systems and different toolchains.

5. Ease of Use

Make:
Make requires you to manually write and manage all the build instructions in the Makefile. This can become complex for large projects with many dependencies. However, for small projects, Makefiles can be simpler and more straightforward.
CMake:
CMake simplifies the process by automatically generating build scripts for different platforms. Once you set up a CMakeLists.txt file, you don’t need to worry about platform-specific details. This makes CMake more user-friendly, especially for larger and cross-platform projects.

6. Flexibility

Make:
Make gives you fine-grained control over every step of the build process. If you need to customize the build process extensively, Make allows you to do so. However, this flexibility comes at the cost of having to write more rules and configurations manually.
CMake:
CMake provides a higher level of abstraction. It simplifies common build tasks but might not offer the same level of control over each step of the process. However, CMake can still be customized using its scripting capabilities if needed.

7. Dependency Management

Make:
In Makefiles, you have to manually specify dependencies between files. If a source file changes, Make checks the dependencies to determine which files need to be recompiled. While this works well, it can be tedious to manage for large projects.
CMake:
CMake automatically manages dependencies by analyzing the CMakeLists.txt file. It can detect source file changes and re-run the necessary build commands. For complex projects, CMake simplifies dependency management by using target_link_libraries() and other CMake functions.

8. Common Use Cases

Make:
- Simple projects or small scripts.
- Projects where the developer needs complete control over the build process.
- Embedded projects targeting a specific platform (if using a specific toolchain).
CMake:
- Large, cross-platform projects.
- Projects that target multiple platforms (e.g., Windows, Linux, macOS) or need to be compiled on different systems.
- Embedded projects with a complex toolchain setup.
- Projects that need to integrate with external libraries or frameworks.

9. Example Workflow

Make:
1. Write a Makefile with rules and dependencies.
2. Run the make command to execute the build process.
3. Manually update the Makefile as the project grows.
CMake:
1. Write a CMakeLists.txt file describing the project configuration.
2. Run cmake to generate the appropriate build system files.
3. Run make or another build tool to compile the project.
4. CMake handles generating platform-specific build scripts automatically.

10. Summary

Feature	Make	CMake
Purpose	Build automation tool	Build system generator
Platform Support	Platform-dependent	Cross-platform
Configuration	Manual configuration in Makefile	Configuration in CMakeLists.txt
Flexibility	High flexibility, but manual	Higher-level abstraction
Ease of Use	Requires manual rules and dependencies	More automated, especially for cross-platform builds
Dependency Management	Manual	Automatic via CMakeLists.txt
Use Case	Small projects, fine-grained control	Large, cross-platform, and complex projects
Toolchain Handling	Manual setup for toolchains	Automatic handling of toolchains

You can also Visit other tutorials of Embedded Prep

Special thanks to @mr-raj for contributing to this article on EmbeddedPrep

May 3, 2025

QNX Boot Process | Master Beginner-Friendly In-Depth Guide 2026

What is Booting?

Booting is like waking up your computer or embedded device. When you press the power button, the system must go from “just hardware” to a fully running operating system (OS) that can run applications.

In QNX Neutrino, the boot process is modular and layered, and it’s built to give maximum flexibility, especially for embedded systems.

QNX Boot Process

The QNX boot process is highly customizable and optimized for real-time embedded

The QNX boot process involves several key steps to bring the system up from power-on to a fully operational state:

Power-On and Bootloader: When the system is powered on, the bootloader is executed. It initializes the hardware (CPU, memory, peripherals) and loads the QNX kernel into memory.
Kernel Loading: The QNX kernel is loaded and starts running. It manages system resources like memory, processes, and interrupts.
System Initialization: The kernel initializes essential services, such as device drivers, file systems, and network services.
User-Space Initialization: The system starts user-space processes and applications, often based on startup scripts. This includes services like login prompts and other essential applications.
Normal Operation: The system enters its normal operational state, ready for user interaction and running background tasks.

Main Components in QNX Boot Sequence

Think of the QNX boot process like climbing a ladder. Each step builds on the one before it and gets closer to running real applications.

Here are the 3 main software pieces involved after the hardware powers up:

IPL (Initial Program Loader)
Startup Program
OS Image (with Kernel and Scripts)

These parts are packaged together in something called an Image File System (IFS).

QNX Boot Process Steps (Simplified with Explanation)

Step 1: Hardware Initialization (Powering On)

This is when the board turns on.
The processor starts executing from a fixed address called the reset vector.
Depending on the hardware, something like a BIOS (x86), UEFI, or U-Boot (ARM) runs first.
These are low-level programs that check the system and hand over control to the QNX boot code.

Step 2: IPL – Initial Program Loader

The IPL is the first piece of QNX software that runs.
It’s very small and is hardware-specific (custom to your board or chip).
The IPL’s job is to:
- Initialize just enough hardware (like RAM or flash).
- Load the rest of the QNX system from storage (like flash, SD card, etc.).
- Specifically, it loads the IFS (Image File System).
- Then, it passes control to the next step — the startup program.

🧠 Think of the IPL as the stage crew that sets the stage and curtain before the actors (OS) come in.

Step 3: Startup Program

The startup program runs immediately after the IPL.
It’s smarter than the IPL and does more complex hardware setup:
- Initializes memory mapping.
- Sets up interrupt controllers, timers, and CPU caches.
- Prepares the environment so the QNX kernel can start.

It’s still inside the IFS (Image File System) that was loaded by the IPL.

Step 4: OS Kernel (procnto)

After startup finishes hardware setup, it hands control to the QNX microkernel (procnto).
procnto includes:
- The QNX kernel.
- The process manager (it handles creating and scheduling programs).
The kernel reads a script from the IFS (defined in the buildfile) and begins launching:
- Drivers (e.g., for serial, USB, or storage).
- System processes (e.g., file systems).
- Initial applications (like the shell or custom software).

This is where QNX becomes a real operating system and starts managing resources, files, and communication.

What is an IFS (Image File System)?

IFS = Bootable image that contains:
- The startup program
- The QNX kernel (procnto)
- Device drivers
- Startup scripts
- Libraries and initial apps

You can think of the IFS like a suitcase with everything QNX needs to boot up and get started.

You create an IFS using a buildfile and the tool mkifs.

How Is the QNX Boot Image Customized?

You can customize what goes into the IFS using a buildfile — a special text file that lists:

What drivers and applications to include
Which order to launch them
Any environment variables or arguments
File permissions and paths

Customization Steps:

Write a Buildfile: [virtual=x86,binary] .bootstrap = { startup-bios } [+script] startup-script.sh /procnto /devc-seromap /sbin/sh
Build the IFS: mkifs buildfile.qnx image.ifs
Flash the IFS to your board or load it via U-Boot.

You control the boot sequence just by editing this buildfile — no need to recompile the entire OS.

💛 Support Embedded Prep

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

What Happens After QNX Boot?

Once everything in the IFS is running, you may still need to start large or complex applications after boot, especially if:

Your app is made of multiple processes.
Processes must start in a specific order.
You want to manage failures or restarts.

For this, QNX provides:

SLM – System Launch and Monitor

Think of it as a supervisor for apps.
It can:
- Launch multiple apps in the correct order.
- Monitor them and restart if needed.
- Let you change startup order without touching the IFS.

Summary Table of QNX Boot Process

Component	Purpose
IPL	Minimal code that loads the IFS (hardware-specific).
Startup	Sets up hardware (timers, cache, MMU) for the kernel.
Kernel (procnto)	Core of QNX; manages memory, processes, threads.
IFS	Boot image with startup, kernel, drivers, apps, scripts.
Buildfile	Text file that defines what goes in the IFS.
SLM	Tool to start complex apps after booting.

May 3, 2025

Master Real-time questions related to QNX in a beginner-friendly and in-depth manner (2026)
Real-time questions related to QNX : Real-time systems are crucial in industries that require highly predictable and time-sensitive operations. In embedded systems, especially in applications like automotive, telecommunications, medical devices, and robotics, real-time performance is not just a feature; it is a necessity. Among the many real-time operating systems available, QNX stands out due to its robustness, modularity, and real-time capabilities.

What is QNX?

QNX is a commercial, Unix-like real-time operating system (RTOS) designed primarily for embedded systems. Unlike general-purpose operating systems, QNX is optimized for real-time performance, meaning it can guarantee responses to inputs within strict time constraints. This ensures that time-sensitive tasks are executed without delay, which is crucial for systems that must respond promptly to external stimuli or control systems.

At its core, QNX utilizes a microkernel architecture. The QNX microkernel is a lightweight and efficient core that handles basic operations such as task scheduling, memory management, and inter-process communication (IPC). Everything else, including device drivers, file systems, and network services, runs in user space, isolated from the kernel. This separation enhances system reliability and fault tolerance, ensuring that if one service fails, it does not affect others.

The Significance of Real-Time Performance

In real-time systems, the concept of time is critical. Real-time performance is classified into two categories:
- Hard Real-Time: Systems that must meet strict deadlines. Missing a deadline could result in catastrophic failures (e.g., life-support systems in hospitals, automotive safety features).
- Soft Real-Time: Systems where deadlines are important but not critical. Missing a deadline does not cause immediate failure, but it may degrade performance or user experience (e.g., streaming services, video conferencing).
QNX is designed to provide hard real-time capabilities, which is essential for applications requiring absolute predictability in time-critical environments. The operating system ensures that tasks are executed within specific time constraints, regardless of system load.

QNX Scheduling and Task Management

One of the most critical aspects of real-time operating systems is how they manage tasks and schedules. In QNX, real-time scheduling is deterministic, meaning it can guarantee that tasks will be executed at the right time without delays.

QNX employs priority-based preemptive scheduling, which ensures that tasks are scheduled according to their urgency. When multiple tasks are ready to execute, the scheduler selects the highest-priority task first. If a higher-priority task becomes ready while a lower-priority task is running, QNX will preempt the current task and execute the higher-priority one immediately. This mechanism helps ensure that critical tasks are always executed on time.

Additionally, round-robin scheduling can be used for tasks with equal priority. In this scheme, each task is given an equal time slice to execute before control is passed to the next task in the queue, ensuring fairness in CPU usage.

Microkernel Architecture and Modularity

The key feature of QNX is its microkernel architecture, which is different from traditional monolithic kernels. In a monolithic kernel, the entire OS runs in supervisor mode, meaning any failure in one part of the OS could affect the entire system. In contrast, QNX’s microkernel only provides essential services, such as managing processes, scheduling, and interrupt handling, while other services like device drivers, file systems, and networking run in user space.

This modular approach offers several benefits:
- Fault Isolation: If one service crashes (e.g., a device driver), it does not bring down the entire system. This isolation improves the system’s stability.
- Flexibility: Developers can customize QNX by adding or removing modules without affecting the core kernel.
- Safety: Critical operations can be isolated, and failures can be contained within their own modules, preventing cascading failures.
The modularity of QNX is beneficial for embedded systems where the operating system needs to be lightweight, flexible, and fault-tolerant.

Real-Time Synchronization in QNX

Synchronization between tasks is essential in a real-time operating system, especially in systems that handle concurrent processes. QNX provides several synchronization mechanisms to manage resource access and ensure tasks execute in a coordinated manner.
1. Mutexes are used to ensure that only one task can access a shared resource at any given time, preventing race conditions.
2. Semaphores help coordinate the execution of multiple tasks. Tasks can signal each other to indicate when they are ready to proceed.
3. Condition Variables allow tasks to wait for specific conditions to be true before they continue executing, offering fine-grained control over task sequencing.
These synchronization tools ensure that tasks in QNX can work together without causing conflicts, delays, or data corruption, which is vital for maintaining real-time performance.

Interrupt Handling in QNX

Interrupts are used to respond to external events in real time, and QNX excels in this area by providing efficient and predictable interrupt handling. The system allows for fast response times to hardware interrupts, ensuring that real-time events are processed immediately.

QNX allows developers to configure Interrupt Service Routines (ISRs), which are specialized functions that respond to interrupts. These routines are designed to execute quickly and efficiently, as interrupt handling must be completed as soon as possible to avoid delays. In addition to regular ISRs, QNX supports threaded ISRs, where interrupt handling can be deferred to a separate thread to process more complex tasks without blocking the real-time system.

Message-Passing and Inter-Process Communication (IPC)

In real-time embedded systems, tasks often need to communicate with one another. QNX uses message-passing as a fundamental mechanism for IPC. This allows different processes (or threads) to exchange data safely without interfering with one another.

QNX offers a range of IPC mechanisms, such as:
- Message Queues: Used for sending and receiving messages between tasks.
- Mailboxes: Specialized message queues with a fixed number of slots, useful for tasks that need to process a stream of messages.
- Signals: A lightweight mechanism to send simple notifications between tasks.
This message-passing system enables real-time tasks to coordinate efficiently and communicate without blocking or delaying critical operations.

Memory Management in QNX

Real-time memory management is another vital aspect of QNX. Memory allocation must be predictable and efficient to avoid delays that could impact real-time performance. QNX employs a real-time memory allocator that ensures quick memory allocation and deallocation while minimizing fragmentation.

One of the key features of QNX is its ability to manage memory across different partitions. Memory resources can be reserved for specific tasks or services, ensuring that each component of the system has the memory it needs to function correctly without interference.

QNX also provides support for shared memory between processes, allowing tasks to share data efficiently while maintaining separation for security and stability.

Fault Tolerance and System Reliability

Reliability and fault tolerance are paramount in real-time systems, and QNX is designed to meet these demands. The system ensures that tasks and processes are isolated from one another, so if one fails, it does not compromise the entire system. Furthermore, watchdog timers can be set up to monitor the system’s health. If a task fails or the system becomes unresponsive, the watchdog timer can trigger a recovery process to restore normal operation.

QNX also supports high-availability and failover mechanisms, which are particularly useful in mission-critical applications like automotive control systems or industrial automation, where system uptime is crucial.

By diving into the details of how QNX works, you can gain the expertise needed to build and optimize embedded real-time applications that meet the strict requirements of modern embedded systems.

💛 Support Embedded Prep

If you find our tutorials helpful and want to support our mission of sharing high-quality embedded system knowledge, you can contribute by buying us a coffee. Every small contribution helps us keep creating valuable content for learners like you. ☕

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

1. How does QNX ensure real-time performance?

QNX is a real-time operating system (RTOS) designed to meet strict timing constraints. It ensures real-time performance through several key features:

Microkernel Architecture
- The QNX microkernel handles only the most critical tasks: scheduling, interrupt handling, interprocess communication (IPC), and synchronization.
- Other services (file system, network, etc.) run in user space, which makes the kernel faster and more predictable.
Priority-based Preemptive Scheduling
- QNX uses fixed-priority preemptive scheduling, where higher-priority tasks preempt lower-priority ones immediately.
- This ensures high-priority tasks meet their deadlines.
Fast Interprocess Communication (IPC)
- QNX’s message-passing IPC is highly optimized and synchronous by default.
- It allows fast and deterministic communication between threads and processes.
Timer Accuracy
- QNX provides high-resolution timers (microsecond accuracy) using its clock and timer services.
- You can schedule precise timeouts, delays, and periodic tasks.
Interrupt Handling
- Interrupt Service Routines (ISRs) are short and quick, and they usually defer processing to threads called Interrupt Threads (i-threads), which are real-time threads.
2. What is priority inversion and how does QNX handle it?

What is Priority Inversion?

It occurs when:
- A low-priority thread holds a shared resource (e.g., a mutex).
- A high-priority thread needs that resource and gets blocked.
- Meanwhile, a medium-priority thread preempts the low-priority one, preventing it from releasing the resource.
This “inverts” the priorities, and the high-priority task waits longer than expected—breaking real-time guarantees.

How QNX handles it

QNX solves this using priority inheritance:
- When a low-priority thread holds a mutex needed by a high-priority thread, QNX temporarily boosts the low-priority thread’s priority to match the high-priority one.
- This allows it to finish its work and release the resource quickly, minimizing the delay.
This mechanism is built into QNX’s native synchronization primitives, like pthread_mutex_t with the PRIO_INHERIT protocol.

3. Example: Writing a real-time application in QNX

Let’s write a simple real-time periodic task in QNX that runs every 1 second to simulate sensor reading.
```
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <pthread.h>
#include <sched.h>
#include <time.h>

void* sensor_task(void* arg) {
    struct timespec interval = {1, 0};  // 1 second
    struct timespec next_time;

    // Get current time
    clock_gettime(CLOCK_REALTIME, &next_time);

    while (1) {
        // Wait until next scheduled time
        next_time.tv_sec += 1;
        clock_nanosleep(CLOCK_REALTIME, TIMER_ABSTIME, &next_time, NULL);

        // Simulate real-time task
        printf("Sensor read at time: %ld\n", time(NULL));
    }

    return NULL;
}

int main() {
    pthread_t thread;
    pthread_attr_t attr;
    struct sched_param param;

    // Set thread attributes
    pthread_attr_init(&attr);
    pthread_attr_setschedpolicy(&attr, SCHED_FIFO); // Real-time policy
    param.sched_priority = 50; // High priority (1-255 in QNX)
    pthread_attr_setschedparam(&attr, &param);
    pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);

    // Create real-time thread
    pthread_create(&thread, &attr, sensor_task, NULL);

    // Join thread (in real use case, main might do other work)
    pthread_join(thread, NULL);
    return 0;
}
```
Explanation:
- We set the thread scheduling policy to SCHED_FIFO (real-time first-in, first-out).
- We use clock_nanosleep with TIMER_ABSTIME to make it wake up precisely every 1 second.
- This is deterministic and respects real-time timing.
Example 1: Real-time Message Passing in QNX

QNX’s microkernel uses synchronous message passing (MsgSend, MsgReceive, MsgReply) for interprocess communication (IPC), ensuring predictable and real-time-safe data exchange.

Goal:

A client sends sensor data to a server (e.g., a data logger) using QNX message passing.

Server Code (real-time receiver):
```
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/neutrino.h>
#include <sys/dispatch.h>

typedef struct {
    int data;
} message_t;

int main() {
    name_attach_t* attach;
    message_t msg;
    int rcvid;

    attach = name_attach(NULL, "SensorServer", 0); // Register name
    if (attach == NULL) {
        perror("name_attach failed");
        exit(1);
    }

    printf("Server running, waiting for messages...\n");
    while (1) {
        rcvid = MsgReceive(attach->chid, &msg, sizeof(msg), NULL);
        if (rcvid == -1) {
            perror("MsgReceive failed");
            continue;
        }
        printf("Received data: %d\n", msg.data);
        MsgReply(rcvid, 0, NULL, 0); // Acknowledge
    }

    name_detach(attach, 0);
    return 0;
}
```
Client Code:
```
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/neutrino.h>

typedef struct {
    int data;
} message_t;

int main() {
    int coid;
    message_t msg = { .data = 42 };

    coid = name_open("SensorServer", 0); // Connect to server
    if (coid == -1) {
        perror("name_open failed");
        exit(1);
    }

    MsgSend(coid, &msg, sizeof(msg), NULL, 0); // Send data
    printf("Message sent!\n");

    name_close(coid);
    return 0;
}
```
Real-Time Note:
- MsgSend() blocks the sender until the server replies—synchronous and deterministic.
- This avoids race conditions and queues, making it real-time safe.
Example 2: Real-Time Interrupt Handling in QNX

Let’s simulate how you’d handle a hardware interrupt (like a GPIO pin going high) using a pulse message from ISR to a thread.

High-level Steps:
1. Register an ISR using InterruptAttach().
2. In ISR, trigger a pulse to a real-time thread.
3. The thread handles actual processing (interrupt thread, or i-thread).
ISR Handler (simplified simulation):
```
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/neutrino.h>
#include <sys/dispatch.h>
#include <signal.h>

#define INTERRUPT_CODE _PULSE_CODE_MINAVAIL

struct sigevent event;

const struct sigevent* isr_handler(void* arg, int id) {
    return &event;  // Send pulse
}

int main() {
    int chid = ChannelCreate(0);
    struct _pulse pulse;

    SIGEV_PULSE_INIT(&event, NULL, SIGEV_PULSE_PRIO_INHERIT, INTERRUPT_CODE, 0);

    int irq = 5; // Example IRQ number
    InterruptAttach(irq, isr_handler, NULL, 0, 0);

    printf("Waiting for pulses...\n");

    while (1) {
        if (MsgReceive(chid, &pulse, sizeof(pulse), NULL) == 0) {
            if (pulse.code == INTERRUPT_CODE) {
                printf("Interrupt received! Handling in thread.\n");
            }
        }
    }

    return 0;
}
```
Real-Time Note:
- The actual ISR (isr_handler) only returns a pulse event (non-blocking and very fast).
- The thread (main) receives the pulse and handles work at a deterministic priority level.
Summary

Feature Benefit in QNX RTOS
MsgSend/Receive Fast, synchronous, real-time-safe IPC
InterruptAttach() Minimal ISR, offloaded to thread via pulse
SCHED_FIFO threads Deterministic thread scheduling
May 3, 2025

Feature	Benefit in QNX RTOS
`MsgSend/Receive`	Fast, synchronous, real-time-safe IPC
`InterruptAttach()`	Minimal ISR, offloaded to thread via pulse
`SCHED_FIFO` threads	Deterministic thread scheduling

Master Networking and Protocols in QNX (Beginner-Friendly guide 2026)

Networking and Protocols in QNX : Networking is an essential part of any modern embedded operating system. QNX, being a real-time operating system (RTOS), supports full TCP/IP networking capabilities, allowing devices to communicate reliably across networks. This article will help you understand:

How the TCP/IP stack is integrated in QNX
How to configure network interfaces
How to implement a basic socket-based server

In QNX, Networking and Protocols refer to the mechanisms that enable communication between devices or systems over a network. QNX is a real-time operating system (RTOS) designed to be used in embedded systems, and it supports various networking features to allow devices to interact, share data, and communicate with one another in a structured manner.

Networking and Protocols in QNX

1. Networking in QNX:

Networking Stack: QNX supports a full networking stack that provides both IPv4 and IPv6 support. This stack enables devices to communicate over Ethernet, Wi-Fi, or other physical communication layers.
IP Networking: QNX provides support for basic Internet Protocol (IP) networking, including IP addressing, routing, and subnetting.
Network Interfaces: QNX can manage different types of network interfaces, including wired (Ethernet) and wireless (Wi-Fi), allowing devices to connect to local networks or the Internet.
Socket API: The QNX networking stack supports sockets, allowing applications to send and receive data over the network using familiar APIs (e.g., BSD socket API).

2. Protocols in QNX:

Transmission Control Protocol (TCP): TCP provides reliable, connection-oriented communication. It is used when data integrity and order are important. It establishes a connection between the sender and receiver before data is transmitted.
User Datagram Protocol (UDP): UDP is a simpler, connectionless protocol that does not guarantee reliable delivery. It’s faster but may lose data during transmission.
Internet Protocol (IP): IP handles addressing and routing of packets across different networks. It’s the foundational protocol that ensures data packets can be routed between devices across networks.
Simple Network Management Protocol (SNMP): SNMP is supported in QNX for network device management and monitoring.
Dynamic Host Configuration Protocol (DHCP): QNX can automatically obtain network configuration (IP address, subnet mask, etc.) from a DHCP server.
Domain Name System (DNS): QNX provides DNS support to resolve human-readable domain names to IP addresses.

3. QNX Network Services:

File System Over Network (NFS): QNX supports NFS, which allows systems to share files over a network as if they were local files.
Remote Procedure Call (RPC): QNX supports RPC, allowing applications to invoke functions in remote systems, effectively enabling distributed systems to communicate.
Virtual Private Network (VPN): QNX also supports VPNs for secure remote communication.

4. QNX Networking Tools:

ifconfig: A command-line utility used to configure network interfaces in QNX.
netstat: A tool used to display network connections, routing tables, and interface statistics.
ping: Used to test the connectivity between two devices over a network.

5. QNX Network Security:

QNX provides support for security features like firewalls, secure socket layers (SSL), and encryption to protect data during transmission.

Practical Applications:

Automotive Systems: Networking protocols are often used in automotive systems for communication between various components of an in-vehicle network.
Industrial Automation: In embedded systems used for industrial automation, QNX networking allows control systems to communicate with sensors, actuators, and other devices.
IoT Devices: QNX powers IoT devices where networking protocols like TCP, UDP, and MQTT are used for device communication.

In summary, networking in QNX provides the essential components to allow embedded systems to communicate over a network using well-known protocols. This is key for many embedded applications that require real-time, reliable, and secure communication between devices.

What is TCP/IP Stack?

TCP/IP is the suite of communication protocols used to connect devices on the Internet or any local network. The stack includes protocols like:

IP (Internet Protocol) – for addressing and routing packets
TCP (Transmission Control Protocol) – for reliable communication
UDP (User Datagram Protocol) – for faster, connectionless communication

How is TCP/IP Stack Integrated in QNX?

QNX integrates the TCP/IP stack as a network manager service. In QNX 6.x and QNX SDP 7.x:

The TCP/IP stack is part of the io-pkt service.
It handles all networking operations.
It’s a modular and pluggable architecture.

Components:

io-pkt-v4-hc or io-pkt-v6-hc – loads the TCP/IP stack (IPv4 or IPv6)
Network drivers are loaded as shared objects (.so files)
TCP/IP library is POSIX-compliant, so standard C sockets work.

Example: Start the TCP/IP Stack

# For IPv4
io-pkt-v4-hc -d rtl8168 -p tcpip

Here:

-d rtl8168: loads the Realtek Ethernet driver
-p tcpip: loads the TCP/IP protocol stack

How Do You Configure Network Interfaces in QNX?

Once the TCP/IP stack is running, you need to configure the IP address and bring up the interface.

Step 1: Identify the network interface

Run:

ifconfig

You’ll see interfaces like en0, en1, etc.

Step 2: Assign an IP address

ifconfig en0 192.168.1.10 netmask 255.255.255.0 up

en0: interface name
192.168.1.10: your IP address
netmask: subnet mask
up: brings the interface online

Step 3: Add a default gateway (optional)

route add default 192.168.1.1

This sets the default route for outbound packets.

Step 4: Test connectivity

ping 192.168.1.1

💛 Support Embedded Prep

Thank you for your support — it truly keeps Embedded Prep growing. 💻✨

How Do You Implement a Socket-Based Server in QNX?

Since QNX uses POSIX-compliant sockets, you can write server/client applications just like in Linux or Unix.

Example: TCP Socket Server in QNX (C Code)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

#define PORT 8080
#define BUFFER_SIZE 1024

int main() {
    int server_fd, client_fd;
    struct sockaddr_in address;
    char buffer[BUFFER_SIZE] = {0};

    // 1. Create socket
    server_fd = socket(AF_INET, SOCK_STREAM, 0);
    if (server_fd < 0) {
        perror("Socket failed");
        exit(EXIT_FAILURE);
    }

    // 2. Bind socket
    address.sin_family = AF_INET;
    address.sin_addr.s_addr = INADDR_ANY;
    address.sin_port = htons(PORT);
    
    if (bind(server_fd, (struct sockaddr*)&address, sizeof(address)) < 0) {
        perror("Bind failed");
        close(server_fd);
        exit(EXIT_FAILURE);
    }

    // 3. Listen for connections
    if (listen(server_fd, 3) < 0) {
        perror("Listen");
        close(server_fd);
        exit(EXIT_FAILURE);
    }

    printf("Server listening on port %d...\n", PORT);

    // 4. Accept client connection
    socklen_t addrlen = sizeof(address);
    client_fd = accept(server_fd, (struct sockaddr*)&address, &addrlen);
    if (client_fd < 0) {
        perror("Accept");
        close(server_fd);
        exit(EXIT_FAILURE);
    }

    printf("Client connected!\n");

    // 5. Receive data
    read(client_fd, buffer, BUFFER_SIZE);
    printf("Client says: %s\n", buffer);

    // 6. Send response
    char* reply = "Hello from QNX server!";
    send(client_fd, reply, strlen(reply), 0);

    // 7. Close sockets
    close(client_fd);
    close(server_fd);
    
    return 0;
}

To compile:

qcc -o qnx_tcp_server server.c

Then run the binary on the QNX target.

Summary

Feature	Description
TCP/IP Stack	Loaded using `io-pkt` service with protocol and driver plugins
Network Config	Use `ifconfig` and `route` commands
Socket Server	Use standard POSIX sockets with `socket()`, `bind()`, `listen()`, `accept()`

Tips for Beginners

Always check if io-pkt is running using pidin ar | grep io-pkt
You can script interface configuration in /etc/system/sysinit
Test server locally using telnet or nc (netcat) commands

May 3, 2025