DEV Community: Amin Khozaei

Reproducible Dev Environments

Amin Khozaei — Thu, 13 Nov 2025 15:02:36 +0000

Modern projects need consistent, repeatable environments across developer machines, CI, and production. Discrepancies between development, testing, and production environments can lead to countless hours of debugging, configuration drift, and frustrating deployment failures. The core challenge is ensuring that every developer, and every server, is working with the exact same set of tools, libraries, and dependencies.

This post explains the ideas behind Nix and Flakes first, then shows how Devbox lets you use those ideas day to day, without writing Nix expressions, and how direnv turns it into a seamless, per‑directory experience.

1. Nix

Nix represents a paradigm shift in package management by utilizing the principles of functional programming to achieve deterministic, reproducible software environments. Unlike traditional systems like apt that modify a global state, Nix manages packages in a purely functional way. This means builds are isolated, dependencies are version-controlled, and state does not interfere across installations. This approach enhances reliability and simplifies configuration management by allowing entire environments to be rolled back, rebuilt, or replicated with precision.

1.1. Core Concepts

Central to Nix’s philosophy is the concept of immutability. In computing, immutability refers to the inability to modify a data object after its creation. In the context of Nix, this means software packages and configurations are never altered once they are built. Each package is associated with a unique identifier, derived from applying a cryptographic hash function to its source code and all its dependencies. This approach ensures that identical builds always produce identical outputs, leading to perfect reproducibility across systems.

A key feature of the Nix package manager is its use of a store, typically located at /nix/store. This directory holds all installed packages. Packages are stored in paths determined by hashing their build instructions and dependencies, ensuring that identical configurations always yield identical paths. For example, a specific version of gcc might live at a path like /nix/store/s66j5b...-gcc-11.3.0/. This thorough approach prevents unplanned modifications or interferences, offering a robust foundation for any reproducible build system.

1.2. Installing Nix

The installation process for Nix varies slightly depending on your operating system. The recommended method is to use the official installer from the Nix Package Manager.

1.2.1. Linux

If you are on Linux running systemd, use Multi-user installation (with root permission):

sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install) --daemon

Otherwise, use Single-user installation (with normal user):

sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install) --no-daemon

1.2.2. MacOS

On MacOS, the only available option is Multi-user, so:

sh <(curl --proto '=https' --tlsv1.2 -L https://nixos.org/nix/install)

1.2.3. Windows

Implementation on Windows environments is markedly different. Windows users need to use the Windows Subsystem for Linux (WSL), which provides a Linux kernel interface within a Windows environment.

First, you are required to enable WSL through Windows PowerShell with administrative privileges:

wsl --install

Following the WSL installation, you must install a Linux distribution, such as Ubuntu, from the Microsoft Store.
Upon launching the installed Linux distribution, you can perform the Linux-based installation as described in section 1.2.1.

After installation, you may need to source the Nix script in your shell's configuration file (e.g., .zshrc, .bashrc) to make the nix command available in new terminal sessions.

1.3. Creating Isolated Environments with `nix-shell`

An essential feature of Nix is the ability to define temporary, isolated environments called Nix shells. This is done by creating a shell.nix file in your project directory. This file declaratively lists all the packages your project needs.

Let's create a simple shell.nix file that provides the hello utility:

# shell.nix
{ pkgs ? import <nixpkgs> {} }:

pkgs.mkShell {
  # buildInputs is the list of packages you want in your environment.
  buildInputs = [ 
    pkgs.hello 
  ];

  # shellHook is a script that runs when you enter the shell.
  shellHook = ''
    export MY_VAR="Hello, Nix!"
  '';
}

To activate this environment, navigate to the project directory and run:

nix-shell

Your shell prompt will change, indicating you are now inside the Nix shell. Here, the hello command is available, and the MY_VAR environment variable is set.

[nix-shell:~/my-project]$ hello
Hello, world!

[nix-shell:~/my-project]$ echo $MY_VAR
Hello, Nix!

When you exit the shell (exit), your original environment is restored, and hello is no longer in your PATH. This powerful feature ensures that project dependencies don't pollute your global system.

2. Nix Flakes

While nix-shell is powerful, it has some reproducibility issues. For instance, import {} points to a "channel" of packages on your system that can change over time, meaning your shell.nix file could produce different environments on different days or different machines.

Flakes are the modern solution to this problem. They are a new feature in Nix designed to improve reproducibility, composability, and usability. Flakes allow hermetic, reproducible evaluation of multi-repository Nix projects, impose a discoverable standard structure, and replace older mechanisms like Nix channels.

2.1. Anatomy of a Flake

A flake is simply a directory containing a flake.nix file. This file has a standardized structure with two main sections: inputs and outputs.

inputs: These are the dependencies of your flake. They can be other flakes, such as the official nixpkgs repository, and are pinned to a specific Git commit.
outputs: These are the things your flake provides, such as packages, development shells (devShells), or NixOS configurations.
All flake inputs are pinned to specific revisions in a lockfile called flake.lock. This file, which is automatically generated and updated, ensures that every evaluation of the flake uses the exact same versions of its dependencies, achieving true reproducibility.

If you've worked with JavaScript (package.json/package-lock.json), Go (go.mod/go.sum), or Rust (Cargo.toml/Cargo.lock), this concept will feel very familiar. flake.nix is like package.json, describing the project, and flake.lock is like package-lock.json, ensuring deterministic builds.

2.2. Enabling Flakes

Flakes are still considered an experimental feature, so you need to enable them.

Temporarily: Add the --experimental-features 'nix-command flakes' flag to any nix command.
Permanently (Recommended): Add the following line to your Nix configuration file.
- On Linux, this is typically /etc/nix/nix.conf.
- On macOS, it's ~/.config/nix/nix.conf.

experimental-features = nix-command flakes

3. Devbox

As you can see, Nix and Flakes provide a robust and powerful system for managing development environments. However, this power comes with a significant learning curve. Mastering the Nix language, which is a purely functional language, understanding its evaluation model, and learning the structure of flake.nix can be a daunting task for developers who just want to install Python and get to work.

This is where Devbox comes in. Devbox is a command-line tool that simplifies the creation and management of isolated, reproducible development environments. It uses Nix and Flakes under the hood, but provides a simple, intuitive interface that feels familiar to anyone who has used tools like npm or yarn.

3.1. Devbox Features

Reproducible Environments with Nix: Devbox uses Nix to create isolated environments. By specifying dependencies in a devbox.json file, Devbox ensures that all team members and CI/CD systems run the same versions of every dependency.
Project-Specific Shell Environments: When you activate a Devbox shell, you enter a dedicated environment where all project-specific dependencies and tools are available, isolated from your system’s global packages. Shell Hooks for Enhanced Customization: Devbox supports shell hooks, which are commands that execute automatically when the environment starts. You can use them to initialize a database, load environment variables, or run setup scripts.
Custom Scripts for Task Automation: You can define custom scripts in your devbox.json to automate routine tasks like starting a dev server (devbox run dev), running tests (devbox run test), or building the project.
Automatic devcontainer.json Generation for VSCode: Devbox can generate a devcontainer.json file, enabling seamless integration with VSCode’s Dev Containers feature. This is perfect for onboarding new developers or working in containerized setups.
Cross-Platform Compatibility: Devbox supports Linux, macOS, and Windows (via WSL), ensuring consistent environments across diverse operating systems.

3.2. Quickstart

Devbox requires the Nix Package Manager. If Nix is not detected when running a command, Devbox will install it for you in single-user mode for Linux.

curl -fsSL https://get.jetify.com/devbox | bash

nix-env -iA nixpkgs.devbox

nix profile install nixpkgs#devbox

Let's see how easy it is to create a deterministic shell with Devbox.

Create a new directory and cd to it and initialize devbox:

mkdir dirbox
cd dirbox
devbox init

Add command-line tools. Let's add Python 3.10 and NodeJS 20. You can search for thousands of available packages on Nixhub.io.

devbox add python@3.10 nodejs@22

Your devbox.json file now tracks these packages:

{
  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.16.0/.schema/devbox.schema.json",
  "packages": [
    "python@3.10",
    "nodejs@22"
  ],
  "shell": {
    "init_hook": [
      "echo 'Welcome to devbox!' > /dev/null"
    ],
    "scripts": {
      "test": [
        "echo \"Error: no test specified\" && exit 1"
      ]
    }
  }
}

Start a new shell that has these tools installed:

devbox shell

Your shell prompt will change to indicate you're in the Devbox shell.

Use your favorite tools. The versions you specified are now available in your PATH.

(devbox) > python --version
Python 3.10.19

(devbox) > node --version
v22.14.0

Your regular system tools and environment variables are also still available.

To exit the Devbox shell and return to your regular shell, simply run:

(devbox) > exit

In just a few commands, you've created a reproducible, isolated development environment without writing a single line of Nix code. Devbox handled the generation of the underlying Nix configuration for you.

4. Automating with Direnv

Devbox makes creating environments easy, but you still have to remember to run devbox shell every time you start working on a project. We can make this even smoother with direnv.

Direnv is an extension for your shell that loads and unloads environment variables depending on your current directory. When you cd into a directory with a .envrc file, direnv automatically executes it, setting up your environment. When you cd out, it cleans up.

4.1. Why Is This Useful?

An isolated environment per project is crucial for several reasons:

Dependency Version Mismatching: Your work project might need NodeJS 18, while a personal project uses NodeJS 20. Devbox solves this, and direnv automates switching between them.
Application Settings: Environment variables like DATABASE_URL or HTTP_PROXY can be set automatically on a per-project basis.
Secrets: API keys and other secrets can be loaded into your environment securely without hardcoding them.
Compiler Options: Flags like LDFLAGS or JAVA_HOME can be configured specifically for the project you're working on.

Traditionally, setting up direnv with Nix required writing a custom .envrc file with a command like use nix. This, again, required some knowledge of the Nix ecosystem.

4.2. Automatic Devbox Environments with Direnv

The Devbox team created a seamless integration with direnv that removes this final piece of manual configuration. With this integration, you don't need to write any .envrc files yourself.

Here’s how to set it up:

Install direnv

nix-env -iA nixpkgs.direnv

For direnv to work properly it needs to be hooked into the shell. Each shell has its own extension mechanism.

bash: Add the following line at the end of the ~/.bashrc file:

eval "$(direnv hook bash)"

zsh: Add the following line at the end of the ~/.zshrc file:

eval "$(direnv hook zsh)"

In your Devbox project directory, Generate the direnv integration file:

devbox generate direnv

This command creates a .envrc file with the content use devbox. You'll be prompted by direnv to allow it to run.

direnv allow

That’s it! Now, whenever you cd into your project directory, your Devbox environment will be activated automatically. When you cd out, it will be unloaded. You get a fully automated, reproducible, and isolated development environment with almost zero effort.

References

PlatformIO: A Better Way to Code for STM32 Microcontrollers

Amin Khozaei — Thu, 05 Dec 2024 20:21:14 +0000

1. STM32 Microcontrollers

The STM32 series is a popular, affordable, and high-performance family of microcontrollers. They enjoy extensive support from various development software suites tailored for microcontrollers. STM32 microcontrollers provide numerous peripherals that can be connected to a wide range of electronic components, such as sensors, displays, and electric motors.

The performance range of STM32 microcontrollers is quite broad. The most basic models, like the STM32F0 and STM32F1 series, start with a clock frequency of 24 MHz and are available in packages with as few as 16 pins. In contrast, the STM32H7 series can operate at speeds of up to 400 MHz and comes in packages with 240 pins. Additionally, the STM32L series is specifically designed for low-power applications that run on small batteries.

To develop code, program the microcontroller, and debug applications, development software is necessary. This software suite should include a compiler, a debugger, and an in-circuit serial programmer (ICSP).

2. PlatformIO

PlatformIO supports a wide range of platforms, architectures, and frameworks, offering modern development capabilities. It is available as an extension in VSCode, making it easy to install and configure with just a few clicks.

To install it, launch VSCode and navigate to the Extensions screen by pressing Ctrl+Shift+X. In the marketplace search bar, type "platformio." It will appear at the top of the search results. Click the Install button, and you're all set!

After a few minutes, the installation is complete, and we now have PlatformIO installed in the VSCode IDE. PlatformIO offers some unique features, the most notable being its declarative development environment. With PlatformIO, we only need to specify the components we will use in our project, including the chip type, the framework, the version of that framework, and any additional libraries with their version constraints. We'll explore the meaning of these components and how to configure a project shortly. Additionally, PlatformIO provides all the essential tools needed for developing embedded projects, such as debugging, unit testing, static code analysis, and firmware memory inspection.

3. ST-LINK

The ST-LINK debugger is a versatile in-circuit debugger and programmer designed for STM32 microcontrollers, developed by STMicroelectronics. It provides a seamless interface for debugging and programming STM32 devices through the SWD (Serial Wire Debug) or JTAG interfaces. The ST-LINK is widely used in development environments due to its compatibility with popular IDEs such as STM32CubeIDE and Keil MDK. It offers features like real-time debugging, breakpoints, and flash programming. Its compact design and ease of use make it an essential tool for developers working with STM32 microcontrollers, facilitating efficient development and troubleshooting of embedded applications.

3.1. Prepare ST-LINK on Linux

In order for OpenOCD to properly access and communicate with USB devices on Linux, it’s essential to add a custom udev rule. By default, OpenOCD may not have the necessary permissions to interact with USB devices like ST-Link. The udev rule grants the appropriate permissions to these devices, ensuring that OpenOCD can successfully connect to them. To do this, you need to create a udev rule file in the /etc/udev/rules.d/ directory, specifying the correct vendor and product IDs of the connected debugger.

By executing the command below, we can find information about our device, including the vendor ID and product ID.

lsusb

We now utilize the device information to create a rule in udev with the following content.

file: /etc/udev/rules.d/99-openocd.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="0483", ATTR{idProduct}=="3748", MODE="0666"

4. Simple LED Blink and USART Project

The blinking LED is often referred to as the “Hello World” of embedded systems because it allows you to verify the basic functionality of the hardware while also providing immediate, visual feedback. When your LED blinks correctly, it means the system is initialized properly and you have control over the microcontroller’s peripherals.

4.1. Go to the PlatformIO Home screen.

4.2. Click on the New Project button on the right of the same screen.

4.3. PlatformIO Project Wizard

A pop-up window appears. Set the project name, select BlackPill F103C8 (Generic) for the board, and specify the framework as STM32Cube Development Framework. You can choose a directory for the project or leave it at the PlatformIO default. Click on Finish to let PlatformIO do its job.

4.4. Directory Structure

When the project is created, we have the following directory structure.

4.5. Peripheral Configuration in STM32CubeMX

STM32CubeMX is an essential tool for anyone working with STM32 microcontrollers. It greatly simplifies the process of configuring microcontroller peripherals and generating initialization code. Without STM32CubeMX, you would have to manually configure each peripheral, set up the clock system, manage pin mappings, and handle low-level register manipulations, all of which can be error-prone and time-consuming.

With STM32CubeMX, you get a graphical interface that streamlines the configuration process, making it easier to start your development work.

4.5.1. Clock Configuration

The Black Pill STM32F103C8 board, which is based on the STM32F103C8 microcontroller, provides several clock sources to operate the system clock and its peripherals.

To achieve a system clock frequency of 72 MHz on the STM32F103C8, you should utilize the Phase-Locked Loop (PLL) along with the High-Speed External (HSE) oscillator as the input clock source.

Now in the clock configuration choose 72 MHz.

4.5.2. Pin Configuration

For this project we used PB7 GPIO pin.

4.5.3. USART Configuration

For this project we used USART1 to sending message from microcontroller. You should Configuring PA9 and PA10 for RX and TX.

After Configuring PA9 and PA10 you should select USART mode.

4.5.4. Code Generating

After configuring the microcontroller, you can generate the necessary initialization code. This code typically involves setting up the clock configuration registers to select the HSE as the PLL source and configuring the PLL multiplier.

4.5.5. Generated Code Structure

The generated code structure is something like the following figure.

For the PlatformIO project, we only need the Inc and Src folders in the Core directory. Copy them from the current location to the corresponding directory in the PlatformIO project structure.

4.6. Coding

The generated code includes multiple comments that guide us on how to modify and add our own code. To achieve our goal, we need to locate the main function, which signifies the start of the program. Inside the main function, we should find the while loop and incorporate the LED toggling logic within it, along with a delay to blink the LED connected to pin B7. Additionally, before entering the while loop, we should send the message "Hello dev.to" at the beginning of the program.

int main(void)
{

  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

  /* MCU Configuration--------------------------------------------------------*/

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_USART1_UART_Init();
  /* USER CODE BEGIN 2 */
  HAL_UART_Transmit(&huart1, (uint8_t *)"Hello dev.to", 13, 1000);
  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    HAL_GPIO_TogglePin(GPIOB, GPIO_PIN_7);
    HAL_Delay(250);
    /* USER CODE END WHILE */
    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

HAL_GPIO_TogglePin: This function toggles the state of the LED pin (turning the LED on and off).
HAL_Delay: This introduces a 500ms delay between toggles, giving the LED a blinking effect.
HAL_UART_Transmit: This transmits the “Hello dev.to” string over USART1 to a connected serial terminal. The huart1 variable is automatically generated in STM32CubeMX and refers to the USART1 handler.

4.7. Build and Run

To build the project, you can use the build button, and to run it, you can click on the Upload button in the PlatformIO extension. Alternatively, you can use the following commands in the PlatformIO terminal emulator inside VSCode.

pio run --environment blackpill_f103c8
pio run --target upload --environment blackpill_f103c8

Resources

Project Source
PlatformIO
STMicroelectronics
Pakdel, M. (2020). Advanced Programming with STM32 Microcontrollers. Elektor.

Oner, V. O. (2021). Developing IoT Projects with ESP32: Automate your home or business with inexpensive Wi-Fi devices. Packt Publishing Ltd.

Automate Versioning with Git and CMake

Amin Khozaei — Tue, 12 Nov 2024 22:25:03 +0000

1. What is Software Versioning?

Software versioning is the practice of assigning unique version numbers to different states or releases of software. This process helps track the software's development, including bug fixes and feature changes over time. It enables developers, teams, and users to understand how the software evolves, what new features have been added, which bugs have been resolved, and what improvements to stability or performance have been made in each release.

Versioning is essential for preserving change histories, ensuring compatibility across various systems, managing dependencies, and providing clarity for end-users and other developers.

Using a formal convention for software versioning is highly beneficial. Once a clear convention is established, it informs all stakeholders—both internal and external—about the software's current state. Without a standardized versioning system, version numbers become meaningless to users and ineffective for managing dependencies. A well-structured version number conveys important information about the version's purpose and the extent of the changes it includes. One widely adopted convention for software versioning is semantic versioning.

1.1. SemVer

Semantic Versioning, often abbreviated as SemVer, is a versioning system used to manage and communicate the evolution of software over time. It provides a structured, predictable way to number software releases, making it clear to developers and users what kind of changes have been made in a particular release.

The version number follows a three-part structure: MAJOR.MINOR.PATCH.

For example, a version number could be 1.5.2, where:

1 is the MAJOR version
5 is the MINOR version
2 is the PATCH version

1.1.1. MAJOR version

The MAJOR version is incremented when there are backward-incompatible changes to the software. This means that changes are significant enough to break existing functionality or APIs that depend on the previous version.
Examples of such changes include removing or renaming functions, changing expected behavior, or modifying core components that affect the user interface or workflow.
Example: If you were to upgrade from 1.0.0 to 2.0.0, this would indicate that the software has undergone significant changes that require users to adjust their workflows or code to remain compatible.

1.1.2. MINOR version

The MINOR version is incremented when backward-compatible features are added to the software. This includes the addition of new features, improvements to existing functionality, or changes that do not disrupt the existing behavior or compatibility of the software.
The key idea here is that users can safely update to the new minor version without worrying about breaking their current workflows.
Example: Upgrading from 1.2.0 to 1.3.0 signifies that new features or improvements were added, but the software remains fully compatible with older versions.

1.1.3. PATCH version

The PATCH version is incremented when backward-compatible bug fixes or minor improvements are made. These changes should not affect the software’s core functionality but are intended to fix issues like bugs, security vulnerabilities, or performance optimizations.
Example: If a release goes from 1.5.2 to 1.5.3, it indicates that bug fixes or minor improvements have been made, but the core functionality of the software has not changed.

1.2. Pre-release Versions

Pre-release versions are crucial for software testing and early feedback. Users and developers can install and test pre-release versions, report bugs, and give feedback before the final stable release.
It’s important to note that pre-release versions are considered unstable, and their behavior may change dramatically between versions. SemVer ensures that developers and users know when to expect such instability and to use these versions with caution.
SemVer also allows for pre-release versions, which are versions of the software that are still under development and might be unstable. These versions can be labeled using a hyphen followed by one or more identifiers.
Pre-release versions are typically assigned to versions before the software is considered ready for general use. These versions can include:

Alpha versions, which are early-stage releases that may be incomplete and have many bugs.
Beta versions, which are more stable than alpha releases but still may have bugs and are intended for broader testing.
Release candidate (RC) versions, which are considered feature-complete and are under final testing before the full release.

2. Automating SemVer with Git

Utilizing Git for source code management alongside automated generation of Semantic Versioning (SemVer) numbers can significantly enhance the efficiency of development and release processes. By integrating Git with appropriate tools, organizations can automate versioning based on repository commits and tags. This methodology proves particularly beneficial for teams engaged in Continuous Integration and Continuous Deployment (CI/CD), promoting a more streamlined workflow.

2.1. Integrating SemVer with CMake

Integrating semantic versioning with CMake provides a structured approach to ensuring that builds are consistently versioned in alignment with Git history. This practice is particularly beneficial for maintaining clarity and consistency across releases.

2.1.1. Template Files

In C/C++ projects, particularly when using build systems like CMake, template files serve as a way to automate the generation of source or header files with specific content that can be configured at build time.
Template files are essentially placeholder files that contain variables or markers. These variables are replaced with specific values during the build process. This approach is useful for dynamically generating configuration headers, version files, or other source files that need to change based on the build context.
Template files often have distinctive suffixes, such as .in. The .in suffix helps developers and build systems recognize that a file is a template, not a regular source or header file. This suffix indicates that the file contains placeholders that need to be replaced with actual values during the build process.

file: version.h.in

#ifndef GSMAPP_VERSION_H
#define GSMAPP_VERSION_H

#define PROJECT_VERSION_MAJOR @PROJECT_VERSION_MAJOR@
#define PROJECT_VERSION_MINOR @PROJECT_VERSION_MINOR@
#define PROJECT_VERSION_PATCH @PROJECT_VERSION_PATCH@
#define PROJECT_VERSION "@PROJECT_VERSION@"
#define FULL_VERSION "@FULL_VERSION@"

#endif

Placeholders (@...@): Each placeholder will be replaced by CMake (or any build system used) with the actual values specified in the CMake configuration process. For example, @PROJECT_VERSION_MAJOR@ might be replaced with 1, @PROJECT_VERSION_MINOR@ with 0, etc.

file: CMakeLists.txt

configure_file(
    ${CMAKE_SOURCE_DIR}/version.h.in
    ${CMAKE_CURRENT_BINARY_DIR}/version.h
)

The configure_file command in CMake is used to read a template file, replace placeholders with actual values, and write the results to a new file.

file: CMakeLists.txt

target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_BINARY_DIR})

The CMake command target_include_directories specifies the include directories to be used by a target (typically an executable or a library) in a project.

2.2. Extract version information from a Git repository

file: cmake/GitVersion.cmake

function(get_version_from_git)
    find_package(Git QUIET)
    if(NOT Git_FOUND)
        message(WARNING "Git not found")
        return()
    endif()

    execute_process(
        COMMAND ${GIT_EXECUTABLE} describe --tags --always
        WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
        OUTPUT_VARIABLE GIT_TAG
        OUTPUT_STRIP_TRAILING_WHITESPACE
        RESULT_VARIABLE GIT_RESULT
    )

    if(NOT GIT_RESULT EQUAL 0)
        message(WARNING "Failed to get git tag")
        return()
    endif()

    execute_process(
        COMMAND ${GIT_EXECUTABLE} rev-parse --short=7 HEAD
        WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}
        OUTPUT_VARIABLE GIT_COMMIT_SHORT_HASH
        OUTPUT_STRIP_TRAILING_WHITESPACE
    )

    string(REGEX REPLACE "^v" "" CLEAN_TAG "${GIT_TAG}")
    if(CLEAN_TAG MATCHES "^([0-9]+)\\.([0-9]+)\\.([0-9]+)(-.*)?$")

        set(PROJECT_VERSION_MAJOR ${CMAKE_MATCH_1})
        set(PROJECT_VERSION_MAJOR ${CMAKE_MATCH_1} PARENT_SCOPE)
        set(PROJECT_VERSION_MINOR ${CMAKE_MATCH_2})
        set(PROJECT_VERSION_MINOR ${CMAKE_MATCH_2} PARENT_SCOPE)
        set(PROJECT_VERSION_PATCH ${CMAKE_MATCH_3})
        set(PROJECT_VERSION_PATCH ${CMAKE_MATCH_3} PARENT_SCOPE)

        set(FULL_VERSION "${CMAKE_MATCH_1}.${CMAKE_MATCH_2}.${CMAKE_MATCH_3}+${GIT_COMMIT_SHORT_HASH}")
        set(FULL_VERSION "${CMAKE_MATCH_1}.${CMAKE_MATCH_2}.${CMAKE_MATCH_3}+${GIT_COMMIT_SHORT_HASH}" PARENT_SCOPE)
        set(PROJECT_VERSION "${CMAKE_MATCH_1}.${CMAKE_MATCH_2}.${CMAKE_MATCH_3}") 
        set(PROJECT_VERSION "${CMAKE_MATCH_1}.${CMAKE_MATCH_2}.${CMAKE_MATCH_3}" PARENT_SCOPE)
    else()
        message(WARNING "Tag '${CLEAN_TAG}' does not match semver format")
    endif()
endfunction()

Finding Git: Checks whether Git is installed and available. The find_package(Git QUIET) command attempts to locate the Git executable without printing messages upon finding Git.
Obtaining the Git Tag: Uses the git describe --tags --always command to retrieve the most descriptive version string possible, based on tags. This command returns the tag name or, if no tag is available, a commit hash.
Getting the Commit Hash: Retrieves the short hash of the current commit, limited to 7 characters. This is useful for constructing unique build identifiers.
Processing the Tag: Removes a leading ‘v’ from the tag name to normalize it using string(REGEX REPLACE "^v" "" CLEAN_TAG "${GIT_TAG}") command.
Semantic Versioning Check: Checks if CLEAN_TAG matches a semantic versioning pattern (e.g., 1.0.0). It captures the major, minor, and patch versions.

2.3. using our custom CMake module

file: CMakeLists.txt

list(APPEND CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
include(GitVersion)
get_version_from_git()

Appending to CMAKE_MODULE_PATH: CMAKE_MODULE_PATH is a list of directories that CMake uses to search for modules when processing include() or find_package() commands. This line adds a directory named cmake (located in the root source directory of the project) to the list of paths where CMake looks for custom modules.
Including the GitVersion Module: The include() command in CMake is used to include and run another CMake script or module file. This command will look for a file named GitVersion.cmake in the directories listed in CMAKE_MODULE_PATH.
Calling get_version_from_git(): This function, defined within the included GitVersion.cmake, is called here to extract version information from the Git repository.

2.4. Printing Version Information

This C code provides a simple function to print version information about an application, highlighting the use of versioning data integrated into the build process.

file: main.c

#include "version.h"

void print_version() {
    printf("Application Version: %s\n", PROJECT_VERSION);
    printf("Full Version: %s\n", FULL_VERSION);
    printf("Version Details:\n");
    printf("Major: %d\n", PROJECT_VERSION_MAJOR);
    printf("Minor: %d\n", PROJECT_VERSION_MINOR);
    printf("Patch: %d\n", PROJECT_VERSION_PATCH);
    printf("Build Date: %s\n", __DATE__);
    printf("Build Time: %s\n", __TIME__);
}

Resources

Conan: Your Embedded Cross-Compilation Champion

Amin Khozaei — Sat, 13 Jul 2024 11:21:31 +0000

In the continuously changing field of software development, modern programming languages such as Rust and Go have established new standards by integrating built-in package managers. These tools have greatly simplified the development process, allowing developers to easily handle dependencies, improve their workflows, and boost productivity. The convenience provided by these package managers underscores the necessity for a strong solution for C++ development.

Conan is a revolutionary package manager created for C++ developers. Conan simplifies and streamlines package management within the C++ ecosystem, making library and dependency management easier than ever. One of Conan's standout features is its strong support for cross-compiling, which is essential for developers working on embedded systems and applications that target multiple architectures.

Conan's cross-compiling capabilities simplify the development process by enabling developers to build and test their applications for different target environments from a single setup. This feature is especially beneficial for projects that need to run on various hardware configurations, ensuring compatibility and performance across the board.

Moreover, Conan supports a wide range of libraries, offering a vast repository that developers can leverage to enhance their projects. This extensive library support ensures that developers have access to the tools and resources they need, reducing the time spent on configuring and managing dependencies.

For organizations with specific requirements, Conan provides the flexibility to manage private packages using Artifactory Community Edition. This integration ensures that sensitive or proprietary packages remain secure and accessible only to authorized personnel, maintaining the integrity and confidentiality of the development process.

1. Integrate Conan as a Dependency Using CMake

CMake's FetchContent module is a powerful feature introduced in CMake 3.11 that allows you to download and incorporate external content (such as source code or scripts) directly into your build process. It is particularly useful for managing project dependencies without requiring pre-installed libraries or packages.

1.1. Key Features of `FetchContent`

Download and Include External Projects: FetchContent can download content from URLs, Git repositories, or local paths. This content can then be included in your build as if it were part of your source tree.
Version Control: By specifying the exact URL or Git tag/branch/commit, you can ensure that your project always uses a specific version of the external content, providing stability and reproducibility.
Automatic Integration: The fetched content can be automatically integrated into the CMake build system, making it straightforward to compile and link against the downloaded content.
Configuration and Customization: You can configure the fetched content using CMake variables, enabling customization and fine-tuning of how the external content is built and used.

1.2. Resolve Canon Dependency in CMake

To handle different host operating systems using CMake's FetchContent, you can conditionally fetch and configure dependencies based on the detected operating system. For our example, we focused on implementing it on a Linux host machine.

include(FetchContent)
FetchContent_Declare(conan
URL https://github.com/conan-io/conan/releases/download/2.3.2/conan-2.3.2-linux-x86_64.tgz
)
FetchContent_Populate(conan)
if (conan_POPULATED)
    set(CONANEXE ${conan_SOURCE_DIR}/conan)
    set(CONAN_AVAILABLE TRUE)
endif()

2. Defining Profiles for Cross-Compiling

In Conan, profiles are used to define settings, options, environment variables, and tools that should be used during the package creation and consumption process. When cross-compiling, it's essential to distinguish between the build and host profiles, and define appropriate toolchains for each.

2.1. Build Profile

The build profile specifies the environment where the build tools will run. This is typically your native machine (e.g., x86_64 Linux) which compiles code.

[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux

2.2. Host Profile

The host profile specifies the environment where the compiled package will run. This can be a different architecture or platform, such as ARM for embedded systems.

[settings]
arch=armv8
build_type=Release
compiler=clang
compiler.cppstd=17
compiler.libcxx=libc++
compiler.version=12
os=Linux
[buildenv]
CC=/usr/local/mdc_sdk_llvm/dp_gea/mdc_cross_compiler/bin/clang
CXX=/usr/local/mdc_sdk_llvm/dp_gea/mdc_cross_compiler/bin/clang++
LD=/usr/local/mdc_sdk_llvm/dp_gea/mdc_cross_compiler/bin/lld
SYSROOT=/usr/local/mdc_sdk_llvm/dp_gea/mdc_cross_compiler/sysroot
CXXFLAGS=--sysroot=/usr/local/mdc_sdk_llvm/dp_gea/mdc_cross_compiler/sysroot
CFLAGS=--sysroot=/usr/local/mdc_sdk_llvm/dp_gea/mdc_cross_compiler/sysroot

3. Third-Party Libraries Using Conan

Conan Center is a central repository of open-source packages, which includes a wide range of libraries ready to be integrated into your projects.

3.1. Searching for Libraries in Conan Center

Visit Conan Center: Go to Conan Center to browse or search for libraries.
Search for a Library: Use the search bar to find the library you need. For example, if you are looking for the eigen library, type "eigen" in the search bar.
Select the Library: Click on the library from the search results to view its details, including versions, available options, and usage instructions.

3.2. Creating a `conanfile.txt` File

The conanfile.txt file is used to define the dependencies and configurations for your project. Here’s an example conanfile.txt for a project that depends on Eigen and Boost libraries:

[requires]
eigen/3.4.0
boost/1.85.0
[generators]
CMakeDeps
CMakeToolchain
[layout]
cmake_layout

4. Integrating Conan with CMake

Integrating Conan with CMake is a common practice to streamline dependency management in C++ projects. Conan handles the downloading and management of dependencies, while CMake orchestrates the build process.

if (${CONAN_AVAILABLE})
    execute_process(COMMAND "${CONANEXE}" install conanfile.txt --build=missing  --profile:build=conan.build --profile:host=conan.host
    WORKING_DIRECTORY ${PROJECT_SOURCE_DIR})
endif()
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_BINARY_DIR}/Release/generators)
include(conan_toolchain)
find_package(Eigen3 REQUIRED)
find_package(Boost REQUIRED COMPONENTS filesystem)

add_executable(${PROJECT_NAME} main.cpp)

target_link_libraries(${PROJECT_NAME} Eigen3::Eigen Boost::filesystem)

5. Use Libraries in Your Code

Now you can include and use the Eigen and Boost libraries in your main.cpp or other source files.

#include <iostream>
#include <Eigen/Dense>
#include <boost/filesystem.hpp>

int main() {
  // Create a 2x2 matrix
  Eigen::MatrixXd m(2, 2);
  m << 1, 2,
       3, 4;

  // Add another matrix
  Eigen::MatrixXd v(2, 2);
  v << 5, 6,
       7, 8;
  m = m + v;

  // Print the resulting matrix
  std::cout << "Resulting matrix:\n" << m << std::endl;
  boost::filesystem::path my_file = "data.txt";

  // Check if the file exists
  if (boost::filesystem::exists(my_file)) {
    std::cout << my_file << " exists." << std::endl;
  } else {
    std::cout << my_file << " does not exist." << std::endl;
  }

  // Create a directory (if it doesn't exist)
  boost::filesystem::path my_dir = "test_dir";
  if (!boost::filesystem::exists(my_dir)) {
    boost::filesystem::create_directory(my_dir);
    std::cout << "Created directory: " << my_dir << std::endl;
  }

  return 0;
}

References

Conan
CMake

Design Patterns for C

Amin Khozaei — Sat, 29 Jun 2024 19:50:26 +0000

In the world of programming languages, C may not have flashy interfaces or trendy web apps. But underneath the surface, C is a key player, powering many of the technologies we rely on every day. It's efficient and has the ability to directly engage with hardware, making it essential in creating the strong foundations for countless technologies, from the computers in our vehicles to the operating systems that manage our devices. Even video games depend on C for seamless gameplay and outstanding performance. While other languages may handle the visuals, C ensures that the engine operates smoothly.

C's power and control come with complexity. Making large, maintainable C projects can be hard. Design patterns help with this. They are proven solutions to common design problems. They help bridge the gap between C's low-level nature and the need for well-structured code. Design patterns help you write cleaner, more readable C code that's easier for you and your team to understand and modify. They make your code flexible and adaptable to future changes.

1. What is a design pattern?

A design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system. These patterns focus on the relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Design patterns are typically classified into three main categories, each addressing a different aspect of software design:

Creational Patterns: These patterns concentrate on creating objects in a controlled and flexible manner, decoupling object creation from specific use to promote reusability and better control over object instantiation.
Structural Patterns: These patterns focus on how classes and objects are organized to create larger structures and functionalities. They provide methods for dynamically altering the code structure or adding new functionalities without significant modifications to the existing code.
Behavioral Patterns: These patterns define how objects communicate with each other, enabling complex interactions and collaboration between different parts of your code. They promote loose coupling and improve the overall organization and maintainability of your software.

1.1. Object-oriented Paradigm

Design patterns are largely influenced by object-oriented programming (OOP) and are categorized using objects, although some patterns can be implemented without them. It is possible to apply design patterns in C by utilizing fundamental concepts such as functions, pointers, and structs. This can enhance code cleanliness and maintainability without relying on object-oriented features.

Even though C lacks built-in object-oriented features like classes and inheritance, it can still achieve object-oriented-like behavior using clever techniques with functions, pointers, and structs. Popular libraries like GLib showcase this by implementing object-oriented features within the C language.

2. Creational Patterns

Creational design patterns provide various object creation mechanisms, which increase flexibility and reuse of existing code.

2.1. Factory design pattern

It provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created. The primary goal of the Factory pattern is to encapsulate the object creation process, making it more modular, scalable, and maintainable.

2.1.1. Key Concepts

Encapsulation of Object Creation: The Factory pattern encapsulates the logic of creating objects, which means that the client code does not need to know the specific classes being instantiated.
Decoupling: It decouples the code that uses the objects from the code that creates the objects, promoting loose coupling.
Flexibility: The pattern allows for adding new types of objects easily without changing the client code.

2.1.2. Example Code

#include <stdio.h>
#include <stdlib.h>

typedef struct {
    void (*draw)();
} Shape;

typedef struct {
    Shape base;
} Circle;

void draw_circle() {
    printf("Drawing a Circle\n");
}

Circle* create_circle() {
    Circle* circle = (Circle*)malloc(sizeof(Circle));
    circle->base.draw = draw_circle;
    return circle;
}

typedef struct {
    Shape base;
} Square;

void draw_square() {
    printf("Drawing a Square\n");
}

Square* create_square() {
    Square* square = (Square*)malloc(sizeof(Square));
    square->base.draw = draw_square;
    return square;
}

typedef enum {
    SHAPE_CIRCLE,
    SHAPE_SQUARE
} ShapeType;

Shape* shape_factory(ShapeType type) {
    switch (type) {
        case SHAPE_CIRCLE:
            return (Shape*)create_circle();
        case SHAPE_SQUARE:
            return (Shape*)create_square();
        default:
            return NULL;
    }
}

int main() {
    // Create a Circle using the factory
    Shape* shape1 = shape_factory(SHAPE_CIRCLE);
    if (shape1 != NULL) {
        shape1->draw();
        free(shape1);
    }

    // Create a Square using the factory
    Shape* shape2 = shape_factory(SHAPE_SQUARE);
    if (shape2 != NULL) {
        shape2->draw();
        free(shape2);
    }

    return 0;
}

2.1.3. Known Uses

libcurl uses factory functions to create and initialize different types of handles for various I/O operations. This is essential for setting up the appropriate environment for the different kinds of operations it supports.

#include <curl/curl.h>

int main(void)
{
    // Initialize CURL globally
    curl_global_init(CURL_GLOBAL_DEFAULT);

    // Create and initialize an easy handle using the factory function
    CURL *easy_handle = curl_easy_init();
    if(easy_handle) {
        // Set options for the easy handle
        curl_easy_setopt(easy_handle, CURLOPT_URL, "http://example.com");
        curl_easy_setopt(easy_handle, CURLOPT_FOLLOWLOCATION, 1L);

        // Perform the transfer
        CURLcode res = curl_easy_perform(easy_handle);
        if(res != CURLE_OK) {
            fprintf(stderr, "curl_easy_perform() failed: %s\n", curl_easy_strerror(res));
        }

        // Clean up the easy handle
        curl_easy_cleanup(easy_handle);
    }

    // Clean up CURL globally
    curl_global_cleanup();

    return 0;
}

2.2. Singleton Pattern

This pattern is useful when exactly one object is needed to coordinate actions across a system. Common examples include configuration objects, connection pools, and logging mechanisms.

2.2.1. Key Concepts

Single Instance: Ensures that only one instance of the struct is created.
Global Access: Provides a global point of access to the instance.
Lazy Initialization: The instance is created only when it is needed for the first time.

2.2.2. Example Code

#include <stdio.h>
#include <stdlib.h>

// Singleton structure
typedef struct {
    int data;
    // Other members...
} Singleton;

// Static variable to hold the single instance
static Singleton* instance = NULL;

// Function to get the instance of the singleton
Singleton* get_instance() {
    if (instance == NULL) {
        instance = (Singleton*)malloc(sizeof(Singleton));
        instance->data = 0; // Initialize with default values
    }
    return instance;
}

// Function to free the instance (optional, for cleanup)
void free_instance() {
    if (instance != NULL) {
        free(instance);
        instance = NULL;
    }
}

int main() {
    // Get the singleton instance and use it
    Singleton* s1 = get_instance();
    s1->data = 42;
    printf("Singleton data: %p\n", s1);

    // Get the singleton instance again
    Singleton* s2 = get_instance();

    printf("Singleton data: %p\n", s2);

    free_instance();
    return 0;
}

The static keyword in the statement static Singleton* instance = NULL; makes the variable private to the file in C. This means that when included in other files, they can't access the instance variable directly and must access it through corresponding functions. The %p in the statement printf("Singleton data: %p\n", s1); prints the address of the s1 variable.

2.2.3. Known Uses

Here's an example of using GLib's main loop in C to handle a simple timer event:

#include <stdio.h>
#include <glib.h>

gboolean timer_callback(gpointer user_data) {
  printf("Timer fired!\n");
  return TRUE; // Keep the timer running
}

int main() {
  GMainLoop *loop = g_main_loop_new(NULL, FALSE); // Create the main loop

  // Set up a timer to fire every 1 second
  guint timer_id = g_timeout_add_seconds(1, (GSourceFunc)timer_callback, NULL);

  printf("Starting the main loop...\n");
  g_main_loop_run(loop); // Run the main loop

  printf("Stopping the main loop...\n");
  g_source_remove(timer_id); // Remove the timer source
  g_main_loop_unref(loop); // Free the loop resources

  return 0;
}

3. Structural Patterns

Structural patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities. These patterns focus on how classes and objects are composed to form larger structures, providing solutions for creating flexible and efficient structures.

3.1. Adapter Patterns

The Adapter design pattern, also known as Wrapper, is a structural pattern that allows incompatible interfaces to work together. It acts as a bridge between two incompatible interfaces by converting the interface of a class into another interface that the client expects. This pattern is particularly useful when integrating existing components with new systems without modifying the existing components.

3.1.1. Key Concepts

Target Interface: The interface that the client expects.
Adaptee: The existing interface that needs to be adapted.
Adapter: A class that implements the target interface and translates the requests from the client to the adaptee.

3.1.2. Example Code

#include <stdio.h>
#include <stdlib.h>

// Old printer interface (Adaptee)
typedef struct {
    void (*print_old)(const char *message);
} OldPrinter;

void old_print(const char *message) {
    printf("Old Printer: %s\n", message);
}

OldPrinter* create_old_printer() {
    OldPrinter* printer = (OldPrinter*)malloc(sizeof(OldPrinter));
    printer->print_old = old_print;
    return printer;
}

// New printer interface (Target)
typedef struct {
    void (*print)(const char *message);
} NewPrinter;

// Adapter
typedef struct {
    NewPrinter base;
    OldPrinter* old_printer;
} PrinterAdapter;

void adapter_print(const char *message) {
    // Adapt the old print method to the new print method
    printf("Adapter: ");
    old_print(message);
}

NewPrinter* create_printer_adapter(OldPrinter* old_printer) {
    PrinterAdapter* adapter = (PrinterAdapter*)malloc(sizeof(PrinterAdapter));
    adapter->base.print = adapter_print;
    adapter->old_printer = old_printer;
    return (NewPrinter*)adapter;
}

// Client code
int main() {
    // Create the old printer (Adaptee)
    OldPrinter* old_printer = create_old_printer();

    // Create the adapter that adapts the old printer to the new interface
    NewPrinter* new_printer = create_printer_adapter(old_printer);

    // Use the new interface to print a message
    new_printer->print("Hello, world!");

    // Cleanup
    free(new_printer);
    free(old_printer);
    return 0;
}

3.1.3. Known Uses

Here is an example that demonstrates an adapter-like approach in GTK+ which provides widgets and functionalities for building graphical user interfaces (GUIs).

#include <gtk/gtk.h>

typedef struct config_data_t {
  char *option_name;
  int option_value;
} config_data_t;

// Adapter function 
void config_data_to_combobox(GtkComboBoxText *combobox, config_data_t *data) {

  // Adaptee
  gtk_combo_box_text_append_text(combobox, data->option_name);
  g_object_set_data(G_OBJECT(combobox), "option-value", GINT_TO_POINTER(data->option_value));
}

static void destroy(GtkWidget *widget, gpointer data) {
  gtk_main_quit();
}

int main(int argc, char *argv[]) {
  gtk_init(&argc, &argv);

  // Create a window
  GtkWidget *window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_window_set_title(GTK_WINDOW(window), "Configuration Options");
  g_signal_connect(window, "destroy", G_CALLBACK(destroy), NULL);

  // Create a vertical box container
  GtkWidget *vbox = gtk_box_new(GTK_ORIENTATION_VERTICAL, 5);
  gtk_container_add(GTK_CONTAINER(window), vbox);

  // Create a label for the combobox
  GtkWidget *label = gtk_label_new("Select an option:");
  gtk_box_pack_start(GTK_BOX(vbox), label, FALSE, FALSE, 5);

  // Create a GtkComboBoxText widget
  GtkWidget *combobox = gtk_combo_box_text_new();
  gtk_box_pack_start(GTK_BOX(vbox), combobox, FALSE, FALSE, 5);

  config_data_t data1 = {"Option 1", 10};
  config_data_t data2 = {"Option 2", 20};

  // Populate the combobox using the adapter function
  config_data_to_combobox(GTK_COMBO_BOX_TEXT(combobox), &data1);
  config_data_to_combobox(GTK_COMBO_BOX_TEXT(combobox), &data2);

  // Show all widgets
  gtk_widget_show_all(window);

  gtk_main();

  return 0;
}

3.2. Facade Design Pattern

The Facade Design Pattern is a structural pattern that offers a simplified interface to a complex subsystem. It consists of creating a single class (the Facade) that provides simplified methods, which then delegate calls to the more complex underlying system, making it easier to use. This pattern provides a unified interface to a set of interfaces in a subsystem, defining a higher-level interface that makes the subsystem easier to use.

3.2.1. Key Concepts

Simplified Interface: The Facade offers a high-level interface that makes the subsystem easier to use.
Encapsulation: It hides the complexities of the subsystem from the client.
Delegation: The Facade delegates the client requests to appropriate components within the subsystem.

3.2.2. Example Code

#include <stdio.h>

// TV component
typedef struct {
    int is_on;
} TV;

void tv_on(TV *tv) {
    tv->is_on = 1;
    printf("TV is ON\n");
}

void tv_off(TV *tv) {
    tv->is_on = 0;
    printf("TV is OFF\n");
}

// DVD Player component
typedef struct {
    int is_on;
    char movie[50];
} DVDPlayer;

void dvd_on(DVDPlayer *dvd) {
    dvd->is_on = 1;
    printf("DVD Player is ON\n");
}

void dvd_off(DVDPlayer *dvd) {
    dvd->is_on = 0;
    printf("DVD Player is OFF\n");
}

void dvd_play_movie(DVDPlayer *dvd, const char *movie) {
    if (dvd->is_on) {
        strcpy(dvd->movie, movie);
        printf("Playing movie: %s\n", dvd->movie);
    } else {
        printf("DVD Player is OFF. Cannot play movie.\n");
    }
}

// Sound System component
typedef struct {
    int is_on;
} SoundSystem;

void sound_on(SoundSystem *sound) {
    sound->is_on = 1;
    printf("Sound System is ON\n");
}

void sound_off(SoundSystem *sound) {
    sound->is_on = 0;
    printf("Sound System is OFF\n");
}

typedef struct {
    TV tv;
    DVDPlayer dvd;
    SoundSystem sound;
} HomeTheaterFacade;

HomeTheaterFacade* create_home_theater() {
    HomeTheaterFacade* theater = (HomeTheaterFacade*)malloc(sizeof(HomeTheaterFacade));
    theater->tv.is_on = 0;
    theater->dvd.is_on = 0;
    theater->sound.is_on = 0;
    return theater;
}

void home_theater_on(HomeTheaterFacade *theater) {
    tv_on(&theater->tv);
    dvd_on(&theater->dvd);
    sound_on(&theater->sound);
    printf("Home Theater is ON\n");
}

void home_theater_off(HomeTheaterFacade *theater) {
    tv_off(&theater->tv);
    dvd_off(&theater->dvd);
    sound_off(&theater->sound);
    printf("Home Theater is OFF\n");
}

void home_theater_play_movie(HomeTheaterFacade *theater, const char *movie) {
    home_theater_on(theater);
    dvd_play_movie(&theater->dvd, movie);
}

int main() {
    // Create the home theater system
    HomeTheaterFacade* theater = create_home_theater();
    // Use the Facade to play a movie
    home_theater_play_movie(theater, "The Matrix");
    // Turn off the home theater system
    home_theater_off(theater);
    // Cleanup
    free(theater);
    return 0;
}

3.2.3. Known Uses

GStreamer uses the Facade pattern to offer a simple interface for creating and managing multimedia pipelines, hiding the complexity of the underlying media processing components.

#include <gst/gst.h>

int main(int argc, char *argv[]) {
    GstElement *pipeline;
    GstBus *bus;
    GstMessage *msg;

    /* Initialize GStreamer */
    gst_init(&argc, &argv);

    /* Build the pipeline using playbin as Facade pattern */
    pipeline = gst_parse_launch("playbin uri=file:///path/to/video", NULL);

    /* Start playing */
    gst_element_set_state(pipeline, GST_STATE_PLAYING);

    /* Wait until error or EOS */
    bus = gst_element_get_bus(pipeline);
    msg = gst_bus_timed_pop_filtered(bus, GST_CLOCK_TIME_NONE, GST_MESSAGE_ERROR | GST_MESSAGE_EOS);

    /* Free resources */
    if (msg != NULL)
        gst_message_unref(msg);
    gst_object_unref(bus);
    gst_element_set_state(pipeline, GST_STATE_NULL);
    gst_object_unref(pipeline);
    return 0;
}

3.3. Proxy Pattern

The Proxy Design Pattern is a structural design pattern that provides a surrogate or placeholder for another object to control access to it. A proxy can perform additional operations, such as access control, lazy initialization, logging, or even caching, before or after forwarding the request to the real object.

3.3.1. Key Concepts

Proxy: The proxy object, which implements the same interface as the real object and controls access to it.
Real Subject: The actual object that performs the operations. The proxy forwards the requests to this object.

3.3.2. Example Code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Image interface
typedef struct {
    void (*display)();
} Image;

// RealImage implementation
typedef struct {
    Image base;
    char *filename;
} RealImage;

void real_image_display(RealImage *real_image) {
    printf("Displaying image: %s\n", real_image->filename);
}

RealImage* create_real_image(const char *filename) {
    RealImage *real_image = (RealImage*)malloc(sizeof(RealImage));
    real_image->base.display = (void (*)())real_image_display;
    real_image->filename = strdup(filename);
    return real_image;
}

// ProxyImage implementation
typedef struct {
    Image base;
    RealImage *real_image;
    char *filename;
} ProxyImage;

void proxy_image_display(ProxyImage *proxy_image) {
    // Add logging functionality
    printf("Proxy: Logging display request for image: %s\n", proxy_image->filename);

    // Lazy initialization of the RealImage
    if (proxy_image->real_image == NULL) {
        proxy_image->real_image = create_real_image(proxy_image->filename);
    }

    // Forward the request to the RealImage
    proxy_image->real_image->base.display(proxy_image->real_image);
}

ProxyImage* create_proxy_image(const char *filename) {
    ProxyImage *proxy_image = (ProxyImage*)malloc(sizeof(ProxyImage));
    proxy_image->base.display = proxy_image_display;
    proxy_image->real_image = NULL;
    proxy_image->filename = strdup(filename);
    return proxy_image;
}

// Client code
int main() {
    // Create the proxy image
    ProxyImage *proxy_image = create_proxy_image("example.jpg");

    // Use the proxy to display the image
    proxy_image->base.display(proxy_image);

    // Clean up
    if (proxy_image->real_image != NULL) {
        free(proxy_image->real_image->filename);
        free(proxy_image->real_image);
    }
    free(proxy_image->filename);
    free(proxy_image);

    return 0;
}

3.3.3. Known Uses

Here’s an example demonstrating how the STM32 HAL library acts as a proxy for hardware, specifically for configuring and using a GPIO pin:

#include "stm32f4xx_hal.h"

// Initialization function for GPIO
void GPIO_Init(void) {
    __HAL_RCC_GPIOA_CLK_ENABLE();  // Enable the GPIOA clock

    GPIO_InitTypeDef GPIO_InitStruct = {0};

    // Configure GPIO pin : PA5 (typically the onboard LED)
    GPIO_InitStruct.Pin = GPIO_PIN_5;
    GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
    GPIO_InitStruct.Pull = GPIO_NOPULL;
    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);
}

// Function to toggle the GPIO pin
void Toggle_LED(void) {
    HAL_GPIO_TogglePin(GPIOA, GPIO_PIN_5);
}

int main(void) {
    // HAL initialization
    HAL_Init();

    // Configure the system clock
    SystemClock_Config();

    // Initialize GPIO
    GPIO_Init();

    // Main loop
    while (1) {
        Toggle_LED();
        HAL_Delay(1000);  // Delay 1 second
    }
}

void SystemClock_Config(void) {
    // System Clock Configuration code
}

4. Behavioral Patterns

Behavioral design patterns are concerned with algorithms and the assignment of responsibilities between objects. These patterns describe not just patterns of objects or classes but also the patterns of communication between them. They help in defining the flow of control and communication between objects.

4.1. Observer Pattern

The Observer Pattern (Publish-Subscribe) is a behavioral design pattern that defines a one-to-many dependency between objects. When one object (the subject) changes state, all its dependents (observers) are notified and updated automatically. This pattern is particularly useful for implementing distributed event-handling systems.

4.1.1. Key Concepts

Subject: The object that holds the state and notifies observers of changes.
Observers: The objects that are notified and updated when the subject changes.

4.1.2. Example Code

#include <stdio.h>

// Subject (weather sensor)
typedef struct weather_sensor_t {
  double temperature;
  void (*update_observers)(weather_sensor_t *sensor); // Function pointer for notifications
} weather_sensor_t;

// Observer (thermostat)
void thermostat_update(weather_sensor_t *sensor) {
  printf("Temperature changed to: %.2f degrees Celsius\n", sensor->temperature);
  // Simulate thermostat adjustment based on temperature
}

// Registering observer with sensor
void register_thermostat(weather_sensor_t *sensor) {
  sensor->update_observers = thermostat_update; // Assign observer function
}

// Simulating temperature change and notification
void weather_sensor_set_temperature(weather_sensor_t *sensor, double temp) {
  sensor->temperature = temp;
  if (sensor->update_observers) {
    sensor->update_observers(sensor); // Call observer function if registered
  }
}

int main() {
  weather_sensor_t sensor;
  register_thermostat(&sensor); // Register thermostat

  weather_sensor_set_temperature(&sensor, 22.3); // Simulate temperature change

  return 0;
}

4.1.3. Known Uses

The signal/slot mechanism in GLib is a great way to illustrate the Observer pattern. In GLib, signals are emitted by objects when certain events occur, and slots (callbacks) are functions that are called in response to those signals.

#include <glib.h>
#include <stdio.h>

// Subject (GObject that emits signals)
typedef struct {
    GObject parent_instance;
    int state;
} MySubject;

typedef struct {
    GObjectClass parent_class;
} MySubjectClass;

enum {
    STATE_CHANGED,
    LAST_SIGNAL
};

static guint my_subject_signals[LAST_SIGNAL] = { 0 };

// Signal emission function
void my_subject_set_state(MySubject *self, int new_state) {
    if (self->state != new_state) {
        self->state = new_state;
        g_signal_emit(self, my_subject_signals[STATE_CHANGED], 0, self->state);
    }
}

#define MY_TYPE_SUBJECT (my_subject_get_type())
G_DECLARE_FINAL_TYPE(MySubject, my_subject, MY, SUBJECT, GObject)

G_DEFINE_TYPE(MySubject, my_subject, G_TYPE_OBJECT)

static void my_subject_class_init(MySubjectClass *klass) {
    my_subject_signals[STATE_CHANGED] = g_signal_new(
        "state-changed",
        G_TYPE_FROM_CLASS(klass),
        G_SIGNAL_RUN_FIRST,
        0,
        NULL,
        NULL,
        NULL,
        G_TYPE_NONE,
        1,
        G_TYPE_INT
    );
}

static void my_subject_init(MySubject *self) {
    self->state = 0;
}

// Observer (callback function)
void on_state_changed(MySubject *subject, int new_state, gpointer user_data) {
    printf("Observer: State changed to %d\n", new_state);
}

// Main function
int main(int argc, char *argv[]) {
    // Initialize GType system
    g_type_init();

    // Create subject instance
    MySubject *subject = g_object_new(MY_TYPE_SUBJECT, NULL);

    // Connect observer to the signal
    g_signal_connect(subject, "state-changed", G_CALLBACK(on_state_changed), NULL);

    // Change state and emit signal
    my_subject_set_state(subject, 10);
    my_subject_set_state(subject, 20);

    // Cleanup
    g_object_unref(subject);

    return 0;
}

4.2. Strategy Pattern

The Strategy Design Pattern is a behavioral design pattern that defines a family of algorithms, encapsulates each one, and makes them interchangeable. This pattern allows the algorithm to vary independently from the clients that use it. The Strategy pattern is particularly useful when you need to switch between different algorithms or behaviors at runtime.

4.2.1. Key Concepts

Strategy Interface: Defines a common interface for all supported algorithms.
Concrete Strategies: Implement the algorithm using the Strategy interface.
Context: Maintains a reference to a Strategy object and uses it to execute the algorithm.

4.2.2. Example Code

‍‍‍

#include <stdio.h>

// Interface for sorting algorithms
typedef int (*sort_function_t)(int *data, size_t data_size);

// Concrete strategy - Bubble sort implementation
int bubble_sort(int *data, size_t data_size) {
  for (size_t i = 0; i < data_size - 1; i++) {
    for (size_t j = 0; j < data_size - i - 1; j++) {
      if (data[j] > data[j + 1]) {
        int temp = data[j];
        data[j] = data[j + 1];
        data[j + 1] = temp;
      }
    }
  }
  return 0;
}

// Concrete strategy - Selection sort implementation
int selection_sort(int *data, size_t data_size) {
  for (size_t i = 0; i < data_size - 1; i++) {
    int min_index = i;
    for (size_t j = i + 1; j < data_size; j++) {
      if (data[j] < data[min_index]) {
        min_index = j;
      }
    }
    if (i != min_index) {
      int temp = data[i];
      data[i] = data[min_index];
      data[min_index] = temp;
    }
  }
  return 0;
}

// Context (sorting utility) using strategy pattern
void sort(int *data, size_t data_size, sort_function_t sort_function) {
  if (sort_function(data, data_size) == 0) {
    printf("Sorting successful!\n");
  } else {
    printf("Error during sorting!\n");
  }
}

int main() {
  int data[] = {5, 2, 8, 1, 3};
  size_t data_size = sizeof(data) / sizeof(data[0]);

  // Choose sorting strategy (can be dynamic based on criteria)
  sort_function_t sort_strategy = bubble_sort;

  sort(data, data_size, sort_strategy);

  return 0;
}

4.2.3. Known Uses

This example will show how to compress data using different zlib compression strategies: default, best speed, and best compression.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <zlib.h>


int main() {
    const char* input_data = "This is some data to be compressed.";
    size_t input_size = strlen(input_data);
    char output_data[100];
    size_t output_size = sizeof(output_data);
    int result;

    // Using default compression level
    result = compress2((Bytef*)output_data, (uLongf*)output_size, (const Bytef*)input_data, input_size, Z_DEFAULT_COMPRESSION);
    if (result == Z_OK) {
        printf("Default compression success. Compressed size: %zu\n", output_size);
    } else {
        printf("Default compression failed.\n");
    }

    // Reset output size for the next test
    output_size = sizeof(output_data);

    // Using best speed compression level
    result = compress2((Bytef*)output_data, (uLongf*)output_size, (const Bytef*)input_data, input_size, Z_BEST_SPEED);
    if (result == Z_OK) {
        printf("Best speed compression success. Compressed size: %zu\n", output_size);
    } else {
        printf("Best speed compression failed.\n");
    }

    // Reset output size for the next test
    output_size = sizeof(output_data);

    // Using best compression level
    result = compress2((Bytef*)output_data, (uLongf*)output_size, (const Bytef*)input_data, input_size, Z_BEST_COMPRESSION);
    if (result == Z_OK) {
        printf("Best compression success. Compressed size: %zu\n", output_size);
    } else {
        printf("Best compression failed.\n");
    }

    return 0;
}

4.3. State Pattern

The State Pattern is a behavioral design pattern that allows an object to alter its behavior when its internal state changes. The object will appear to change its class. This pattern is particularly useful when an object must change its behavior at runtime depending on its state.

4.3.1. Key Concepts

Context: The object whose behavior varies based on its state. It maintains a reference to an instance of a state subclass that defines the current state.
State Interface: Declares methods that concrete states must implement.
Concrete States: Implement the behavior associated with a state of the Context.

4.3.2. Example Code

"Hunt the Wumpus" is a classic text-based adventure game where the player navigates through a network of interconnected rooms in a cave system to hunt a creature called the Wumpus. The player can move through rooms, shoot arrows to kill the Wumpus, and must avoid various hazards such as bottomless pits and super bats. The game provides sensory hints, like smells and sounds, to help the player deduce the locations of the Wumpus and hazards. The player wins by successfully shooting the Wumpus with an arrow, and loses if they enter a room with the Wumpus, fall into a pit, or get carried away by bats. Here's an example in C that implements a simplified Wumpus game and saves state using the State pattern:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

// Game constants
#define ROOMS 5

// Forward declaration of Context
typedef struct Player Player;

// State interface
typedef struct PlayerState {
    void (*move)(Player*, int);
} PlayerState;

// Context
struct Player {
    PlayerState* state;
    int current_room;
    void (*set_state)(Player*, PlayerState*);
};

// Function to set the state
void set_player_state(Player* player, PlayerState* state) {
    player->state = state;
}

// Function to create a Player
Player* create_player() {
    Player* player = (Player*)malloc(sizeof(Player));
    player->state = NULL;
    player->current_room = 0;
    player->set_state = set_player_state;
    return player;
}

// Forward declarations of state structs
extern PlayerState alive_state;
extern PlayerState dead_state;
extern PlayerState won_state;

// Concrete State: Alive
void alive_move(Player* player, int room);
PlayerState alive_state = { alive_move };

void alive_move(Player* player, int room) {
    player->current_room = room;
    printf("Player moves to room %d.\n", room);
    // For simplicity, let's assume:
    // Room 2 has the Wumpus, Room 4 has the gold.
    if (room == 2) {
        printf("Player encountered the Wumpus and died!\n");
        player->set_state(player, &dead_state);
    } else if (room == 4) {
        printf("Player found the gold and won!\n");
        player->set_state(player, &won_state);
    }
}

// Concrete State: Dead
void dead_move(Player* player, int room);
PlayerState dead_state = { dead_move };

void dead_move(Player* player, int room) {
    printf("Player is dead and cannot move.\n");
}

// Concrete State: Won
void won_move(Player* player, int room);
PlayerState won_state = { won_move };

void won_move(Player* player, int room) {
    printf("Player has already won and cannot move.\n");
}

// Client code
int main() {
    // Create a player
    Player* player = create_player();

    // Initial state: Alive
    player->set_state(player, &alive_state);

    // Move the player to different rooms
    player->state->move(player, 1); // Move to room 1
    player->state->move(player, 2); // Encounter the Wumpus and die
    player->state->move(player, 3); // Cannot move because player is dead

    // Reset player to alive state for the next test
    player->set_state(player, &alive_state);

    player->state->move(player, 3); // Move to room 3
    player->state->move(player, 4); // Find the gold and win
    player->state->move(player, 5); // Cannot move because player has won

    // Clean up
    free(player);

    return 0;
}

4.3.3. Known Uses

In GStreamer, the State pattern is used to handle the state transitions of a media pipeline. The states control the flow of media data through the pipeline, ensuring that elements are properly initialized, negotiated, and ready to process media data.

#include <gst/gst.h>

// Function to change the state of the pipeline and print the new state
void change_pipeline_state(GstElement *pipeline, GstState state) {
    GstStateChangeReturn ret = gst_element_set_state(pipeline, state);

    if (ret == GST_STATE_CHANGE_FAILURE) {
        g_printerr("Unable to set the pipeline to the desired state.\n");
        return;
    }

    GstState current_state;
    gst_element_get_state(pipeline, &current_state, NULL, GST_CLOCK_TIME_NONE);
    g_print("Pipeline state changed to %s\n", gst_element_state_get_name(current_state));
}

int main(int argc, char *argv[]) {
    gst_init(&argc, &argv);

    // Create the pipeline
    GstElement *pipeline = gst_pipeline_new("example-pipeline");

    // Set the pipeline to the NULL state
    change_pipeline_state(pipeline, GST_STATE_NULL);

    // Set the pipeline to the READY state
    change_pipeline_state(pipeline, GST_STATE_READY);

    // Set the pipeline to the PAUSED state
    change_pipeline_state(pipeline, GST_STATE_PAUSED);

    // Set the pipeline to the PLAYING state
    change_pipeline_state(pipeline, GST_STATE_PLAYING);

    // Clean up
    gst_object_unref(pipeline);
    gst_deinit();

    return 0;
}

References

Websites

Books

E. Gamma, R. Helm, R. Johnson, and J. Vlissides (1994). Design Patterns: Elements of Reusable Object-Oriented Software.

Douglas, B. (2010). Design Patterns for Embedded Systems in C.

Yocto: roll your own embedded Linux distribution

Amin Khozaei — Mon, 08 Apr 2024 09:09:58 +0000

What is Linux?

Linux is an impressive operating system that can run on a wide range of devices, from supercomputers to cell phones, manufacturing devices, network switches, and even cow milking machines. What's even more amazing is that this software is maintained by thousands of skilled software engineers and is available for free.

Initially, Linux was not developed as an embedded operating system. Instead, it was created by Linus Torvalds, a Finnish university student, who made his work available to everyone, accepted feedback from others, and delegated tasks to other skilled engineers. As the project grew, it attracted more talented engineers who contributed to Linux, increasing its value and visibility and thus creating a virtuous cycle that continues to this day.

Linux was first designed to run on the Intel IA-32 architecture and later ported to a Motorola processor. The porting process was difficult, so Linus Torvalds decided to redesign the architecture so that it could be easily ported, creating a clean interface between the processor-dependent parts of the software and those that are architecture independent. This decision paved the way for Linux to be ported to other processors.

Linux is a kernel that manages communication between software and hardware, but it is not very useful on its own. Linux distributions combine software from various projects to create a complete operating system. Popular distributions include Debian, Ubuntu, Fedora, Red Hat, and CentOS, which cater to different use cases such as desktops, servers, and embedded devices. Although these distributions share the same major Linux kernel version, each one curates a specific set of system software, libraries, and functionalities to meet different user needs and hardware architectures. The portability of Linux software, such as the GNU toolchain, has contributed to its success in embedded systems. Much of this software was designed to be adaptable across platforms, making it a perfect fit for resource-constrained embedded devices. This has extended the reach of Linux far beyond traditional desktops.

Why Use Embedded Linux?

Embedded Linux is similar to the Linux distributions that run on millions of desktops and servers worldwide, but it is tailored to a specific use case. Unlike desktop and server machines, embedded devices have limited resources such as memory, processor cycles, power consumption, and storage space. These resources matter a lot in the embedded field because they determine the unit cost of a device that may be produced in the millions. For instance, even a few extra MB or GB of storage can significantly impact the cost of a device. Similarly, extra memory may require additional batteries, which can add weight to the device. Moreover, a processor with a high clock speed produces heat, and some environments have very tight heat budgets, which means only limited cooling is available. Therefore, in embedded programming, if you're using Linux or some other operating system, most of the efforts focus on optimizing limited resources to make the most out of them.

When it comes to embedded operating systems, Linux is not the most lightweight option available, as compared to others like VxWorks, Integrity, and Symbian. Some embedded applications make use of frameworks like ThreadX for application support, which runs directly on the hardware, without the need for an operating system. Another option is to skip the framework and write code that runs directly on the device's processor.

The main difference between using a traditional embedded operating system and Linux is the separation between the kernel and the applications. In Linux, applications run in an execution context that is entirely separate from the kernel. This means that the application cannot access memory or resources other than what the kernel allocates. This high level of process protection ensures that if a program is defective, it is isolated from the kernel and other programs, resulting in a more secure and robust system. However, this protection comes at a cost.

The adoption of Linux is on an increasing trend despite its high resource overhead when compared to other options. This suggests that engineers working on projects find the added cost of Linux to be worth it. Although the cost and power demands of system-on-chip (SOC) processors have decreased in recent years, to the extent that they are no more expensive than a low-power 8-bit microcontroller from the past, more sophisticated processors can still be used where necessary. Many design solutions utilize off-the-shelf SOC processors and don't run the leads from the chip for the Ethernet, video, or other unused components.

Linux has become popular due to its ability to provide unique capabilities and features that aren't available in other embedded solutions. These capabilities are crucial to implementing sophisticated designs that distinguish devices in today's market. The open-source nature of Linux allows embedded engineers to take advantage of the continuous development happening in the open-source environment. This development occurs at a pace that no single software vendor can match.

Here's where Embedded Linux shines, offering a compelling combination of technical advantages:

Modular Kernel and Open-Source Power: The core strength of Embedded Linux lies in the modularity of the Linux kernel. This allows developers to include only the necessary components, minimizing resource usage and optimizing performance for the specific hardware. Additionally, the open-source nature of Linux grants access to a vast developer community and a wealth of existing code, accelerating development and reducing costs.
Robust Network Stack: Embedded Linux boasts a mature and reliable network stack, a crucial element for devices that need to communicate with other systems. This stack provides functionalities like TCP/IP (Transmission Control Protocol/Internet Protocol), enabling functionalities like file transfer, remote access, and internet connectivity. Protocols like Wi-Fi, Bluetooth, and cellular networking can also be integrated, allowing embedded devices to seamlessly connect to various networks.
SSH (Secure Shell) for Secure Remote Access: Embedded Linux often includes SSH, a secure communication protocol that allows developers and administrators to remotely access and manage devices. This eliminates the need for physical interaction with potentially hard-to-reach devices, streamlining maintenance and troubleshooting processes.
Web Server Capabilities: For embedded devices that need to serve web content, lightweight web servers like Lighttpd or uhttpd can be incorporated within the Embedded Linux system. These servers are ideal for situations where a full-fledged web server might be overkill, offering a resource-efficient way to provide a web interface for configuration or data visualization.
C Library ( libc ): The C library, or libc, is a fundamental component of Embedded Linux. It provides a collection of essential functions for C programming, simplifying common tasks like memory management, input/output operations, and string manipulation. This rich library empowers developers to create efficient and portable C applications for embedded systems.

What is Yocto?

The Yocto Project is an open-source collaboration project that provides templates, tools, and methods to help us create customized Linux-based systems for embedded products, regardless of the hardware architecture. It can generate tailored Linux distributions based on the glibc and musl C standard libraries, as well as Real-Time Operating System (RTOS) toolchains for bare-metal development.
The Yocto Project aggregates several companies, communities, projects, and tools with the same purpose – to build Linux-based embedded products. These stakeholders are in the same boat, driven by their community needs to work together.
The Yocto Project provides various tools that prepare its build environment, utilities, and toolchains, which minimize the host software dependency. These tools are independent of the host Linux distribution, which reduces the number of host utilities required to produce the same result. This has an essential benefit of considerably increasing determinism, reducing build host dependencies, and increasing first-time builds.

Background

The OpenEmbedded project was initiated in January 2003 by core developers from the OpenZaurus project. They began working with a new build system, which led to the development of the OpenEmbedded build system. This build system is inspired and based on the Gentoo Portage package system called BitBake. As a result, the project has grown its software collection and the list of supported machines has expanded rapidly.
Due to the chaotic and uncoordinated development of OpenEmbedded, it was quite challenging to use it in products that require a more stable and polished code base. This led to the birth of the Poky distribution, which started as a subset of the OpenEmbedded build system. Poky had a more polished and stable code base across a limited set of architectures. Moreover, its reduced size allowed Poky to develop highlighting technologies, such as IDE plugins and Quick Emulator (QEMU) integration, which are still in use today.
In an effort to streamline their work, the Yocto Project and OpenEmbedded project joined forces to create a core build system known as OpenEmbedded Core. This system combines the best elements of both Poky and OpenEmbedded, with a focus on incorporating additional components, metadata, and subsets. In November of 2010, the Linux Foundation announced that the Yocto Project would take over this work as a sponsored project.

Poky

Poky is a reference distribution of the Yocto Project that utilizes the OpenEmbedded build system technology. It consists of a set of tools, configuration files, and recipe data (called metadata), that is platform-agnostic and supports cross-compiling through the BitBake tool, OpenEmbedded Core, and a default set of metadata. Additionally, it offers the capability to merge and build numerous distributed open-source projects to create a fully customizable, comprehensive, and coherent Linux software stack.

BitBake

BitBake is a powerful task scheduling and execution system that can parse Python and Shell Script code. The code parsed by BitBake generates and runs tasks, which are a set of steps ordered as per the code's dependencies.

With BitBake, you can evaluate all available metadata, manage dynamic variable expansion, dependencies, and code generation. It also keeps track of all tasks to ensure their completion, maximizing the use of processing resources to reduce build time and improve predictability.

OpenEmbedded Core

The OpenEmbedded Core metadata collection provides the engine of the Poky build system. It provides the core features and aims to be generic and as lean as possible. It supports seven different processor architectures (ARM, ARM64, x86, x86-64, PowerPC, PowerPC 64, MIPS, MIPS64, RISC-V32, and RISC-V 64), only supporting platforms to be emulated by QEMU.

Metadata

The metadata comprises both recipes and configuration files, which are composed of a combination of Python and Shell Script text files, making it an incredibly flexible tool. Poky utilizes this metadata to expand OpenEmbedded Core and includes two different layers, each of which is a subset of metadata. These layers are:

meta-poky: This layer provides the default and supported distribution policies, visual branding, and metadata tracking information such as maintainers, upstream status, etc. This layer is designed to act as a curated template that could be utilized by distribution builders to create their own custom distribution.
meta-yocto-bsp: This layer provides the Board Support Package (BSP) used as the reference hardware for the Yocto Project development and Quality Assurance (QA) process.

The Yocto Project releases

The Yocto Project has a biannual release cycle in April and October. This ensures continuous development while focusing on stability and providing points of increased testing. A release is considered Stable or Long-Term Support (LTS) depending on its readiness.

The support period for each release differs significantly. The stable release is supported for 7 months, with 1 month of overlapped support for every stable release. The LTS release, on the other hand, has a minimum support period of 2 years, which can be optionally extended.

After the official support period ends, a release moves to Community support and eventually reaches End of Life (EOL). A release becomes Community supported if a community member becomes the community maintainer. If there is no change in the source code for 2 months or the community maintainer is no longer active, the release reaches EOL.

You can access the release information of the Yocto Project by using the release page.

Preparing Build System

The process needed to set up our host system depends on the Linux distribution we use. Poky has a set of supported Linux distributions. Let’s suppose we are new to embedded Linux development. In that case, it is advisable to use one of the supported Linux distributions to avoid wasting time debugging issues related to the host system support.
If you use the current release of one of the following distributions, you should be good to start using the Yocto Project on your machine:

Ubuntu
Fedora
CentOS
AlmaLinux
Debian
OpenSUSE Leap

If your preferred distribution is not in the preceding list, it doesn’t mean it is not possible to use Poky on it. Your host development system must meet some specific versions for Git, tar, Python, and GCC. Your Linux distributions should provide compatible versions of those base tools.

Debian-based distribution

To install the necessary packages for a headless host system, run the following command:

sudo apt install gawk wget git diffstat unzip texinfo gcc
build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev pylint3 xterm python3-subunit mesa-common-dev zstd liblz4-tool

If you have Ubuntu, your default shell is dash. Some scripts might have a problem with it, so you should change dash to bash with the command below:

dpkg-reconfigure dash

and select "NO" on the prompt.

Fedora

To install the needed packages for a headless host system, run the following command:

sudo dnf install gawk make wget tar bzip2 gzip python3 unzip perl patch diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat python3-pexpect findutils which file cpio python python3-pip xz python3-GitPython python3-jinja2 SDL-devel xterm rpcgen mesa-libGL-devel perl-FindBin perl-File-Compare perl-File-Copy perl-locale zstd lz4

Downloading the Poky source code

After we have installed the required packages on our development host system, we can download the current LTS version (at the time of writing) of Poky source code using Git, with the following command:

git clone https://git.yoctoproject.org/poky -b Scarthgap

Preparing the build environment

Inside the poky directory exists a script named oe-init-build-env, which sets up the building environment. But first, the script must be run-sourced (not executed) as follows:

source oe-init-build-env [build-directory]

Here, [build-directory] is an optional parameter for the name of the directory where the environment is configured. If it is empty, it defaults to build. The [build-directory] parameter is the place where we perform the builds.
The output from source oe-init-build-env build displays some important configurations such as the file location, some project URLs, and some common targets, such as available images.

Knowing the local.conf file

When we initialize a build environment, it creates a file called build/conf/local.conf. This config file is powerful, since it can configure almost every aspect of the build process. We can set the target machine and the toolchain host architecture to be used for a custom cross-toolchain, optimize options for maximum build time reduction, and so on. The comments inside the build/conf/local.conf file are excellent documentation and a reference of the possible variables and their defaults. The minimal set of variables that we probably want to change from the default is the following:

MACHINE ??= "qemux86-64"

The MACHINE variable is where we determine the target machine we wish to build. At the time of writing, Poky supports the following machines in its reference BSP:

beaglebone-yocto: This is BeagleBone, which is the reference platform for 32-bit ARM
genericx86: This is generic support for 32-bit x86-based machines
genericx86-64: This is generic support for 64-bit x86-based machines
edgerouter: This is EdgeRouter Lite, which is the reference platform for 64-bit MIPS The machines are made available by a layer called meta-yocto-bsp. Besides these machines, OpenEmbedded Core, inside the meta directory, also provides support for the following Quick Emulation (QEMU) machines:
qemuarm: This is the QEMU ARMv7 emulation
qemuarmv5: This is the QEMU ARMv5 emulation
qemuarm64: This is the QEMU ARMv8 emulation
qemumips: This is the QEMU MIPS emulation
qemumips64: This is the QEMU MIPS64 emulation
qemuppc: This is the QEMU PowerPC emulation
qemuppc64: This is the QEMU PowerPC 64 emulation
qemux86-64: This is the QEMU x86-64 emulation
qemux86: This is the QEMU x86 emulation
qemuriscv32: This is the QEMU RISC-V 32 emulation
qemuriscv64: This is the QEMU RISC-V 64 emulation Extra BSP layers available from several vendors provide support for other machines.

Building a target image

Poky provides several predesigned image recipes we can use to build our binary image. We can check the list of available images by running the following command from the poky directory:

ls meta*/recipes*/*images/*.bb

All the recipes provide images that are a set of unpacked and configured packages, generating a filesystem that we can use with hardware or one of the supported QEMU machines.
Next, we can see the list of most commonly used images:

core-image-minimal: This is a small image allowing a device to boot. It is handy for kernel and bootloader tests and development.
core-image-base: This console-only image provides basic hardware support for the target device.
core-image-weston: This image provides the Wayland protocol libraries and the reference Weston compositor.
core-image-x11: This is a basic X11 image with a terminal.
core-image-sato: This is an image with Sato support and a mobile environment for mobile devices that use X11. It provides applications such as a terminal, editor, file manager, media player, and so on.
core-image-full-cmdline: A console-only image with more full-featured Linux system functionality installed.

For example, to build core-image-full-cmdline, run the following command:

bitbake core-image-full-cmdline

Running images in QEMU

We can use hardware emulation to speed up the development process, as it enables a test run without involving any actual hardware. Fortunately, most projects have only a tiny portion that is hardware-dependent.
QEMU is a free, open source software package that performs hardware virtualization. QEMU-based machines allow testing and development without real hardware. ARMv5, ARMv7, ARMv8, MIPS, MIPS64, PowerPC, PowerPC 64, RISC-V 32, RISC-V 64, x86, and x86-64 emulations are currently supported. We will go into more detail about QEMU usage in sw, Speeding Up Product Development through Emulation – QEMU.
OpenEmbedded Core provides the runqemu script tool, which is a wrapper to make use of QEMU easier. The way to run the script tool is as follows:

runqemu [machine] [zimage] [filesystem]

Here, [machine] is the machine/architecture to be used as qemux86-64, or any other supported machine. Also, [zimage] is the path to a kernel (for example, bzImage-qemux86-64.bin).
Finally, [filesystem] is the path to an ext4 image (for example, filesystem-qemux86-64.ext4) or an NFS directory. All parameters in the preceding call to runqemu [zimage] and [filesystem] are optional. Just running runqemu is sufficient to launch the image in the shell where the build environment is set, as it will automatically pick up the default settings from building the environment. For example:

runqemu qemux86-64 core-image-full-cmdline

References

Salvador, O., & Angolini, D. (2017). Embedded Linux Development using Yocto Projects: Learn to leverage the power of Yocto Project to build efficient Linux-based products. Packt Publishing Ltd.

Simmonds, C. (2017). Mastering Embedded Linux Programming. Packt Publishing Ltd.

Sally, G. (2010). Pro Linux embedded systems. Apress.

MISRA C Standard

Amin Khozaei — Sun, 24 Mar 2024 14:09:58 +0000

C Programming Language

Over half a century ago, in the year 1969, the C programming language was created at Bell Labs. The primary goal was to use this language for developing the Unix operating system, which turned out to be a highly successful venture. Despite receiving frequent criticism, C is still one of the most widely used programming languages globally, and it is the most popular one for developing embedded systems.

The reasons behind C's popularity and success are many and varied. First, C compilers are available for nearly every processor, ranging from tiny DSPs used in hearing aids to supercomputers. This versatility makes it possible to use C for a wide range of applications.

Furthermore, C compiled code can be highly efficient without hidden costs. Programmers can predict running times to some extent even before testing, without using tools for the worst-case execution time approximation. This saves a lot of time and effort and helps to streamline the development process.

Additionally, C allows writing compact code thanks to limited verbosity and the availability of many built-in operators. This feature makes it easier to write and debug code, which can result in faster development times.

It is worth noting that C is defined by international standards. It was first standardized in 1989 by the American National Standards Institute (referred to as ANSI C), and then by the International Organization for Standardization (ISO). This ensures that C is a highly reliable and stable programming language.

Moreover, C, possibly with extensions, allows easy access to the hardware, a crucial aspect for developing embedded software. This feature provides developers with greater control over the hardware, making it easier to optimize performance and functionality.

C has a long history of usage in all kinds of systems, including safety, security, mission, and business-critical systems. This makes it a highly versatile programming language that can be used in a wide range of applications.

Lastly, C is widely supported by all sorts of tools, making it easier to develop and maintain software written in C. This includes compilers, debuggers, and other software development tools.

C Is Not Fully Defined

There are claims that C++ will eventually replace C, but this is unlikely in the embedded software industry. C++ is a very complex language that is constantly evolving, which contrasts with industrial best practices. C, on the other hand, is a stable and compact language. However, C is subject to criticism regarding its behavior and the as-if rule. This rule allows the compiler to optimize the code while maintaining the observable behavior. C is not fully defined in this respect, and there are four classes of non-definite behaviors.

Implementation-defined behavior: unspecified behavior where each implementation documents how the choice is made; e.g., the sizes and precise representations of the standard integer types;
Locale-specific behavior: behavior that depends on local conventions of nationality, culture, and language that each implementation documents; e.g., character sets and how characters are displayed;
Undefined behavior: behavior, upon use of a non-portable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements; e.g., attempting to write a string literal constant or shifting an expression by a negative number or by an amount greater than or equal to the width of the promoted expression;
Unspecified behavior: use of an unspecified value, or other behavior where this International Standard provides two or more possibilities and imposes no further requirements on which is chosen in any instance;e.g., the order in which sub-expressions are evaluated.

Non-definite behavior in programming languages is a result of two factors. Firstly, efficient compilers can be written for almost any hardware architecture. Secondly, there are many compilers available from different vendors, and the language is standardized.

Regarding the second point, it's important to note that ISO typically standardizes existing practices while considering input from participating vendors. They also prioritize backward compatibility. Therefore, when there are divergent implementations, non-definite behavior may be the only feasible solution.

In C, the main objective is to obtain efficient code with no hidden costs. This is the reason why there is no run-time error checking. However, easy access to hardware can make it simple to corrupt the program state.

One of the drawbacks of code compactness is that the language can be easily misunderstood and misused.

The C language is expected to remain true to its original purpose and will continue to be used in the development of embedded systems. However, it is worth noting that certain features of C may conflict with safety and security requirements. Therefore, it is essential to subset the language for critical applications. This has been recognized early and is now mandated or recommended by various safety and security-related industrial standards, such as IEC 61508 for industrial applications, ISO 26262 for automotive, CENELEC EN 50128 for railways, RTCA DO-178B/C for aerospace, and FDA's General Principles of Software Validation.

C Can Be Difficult To Read

It is important to use C language features correctly, as improper usage can adversely affect the readability and understandability of the program. Some of the features that can cause issues are:
• The preprocessing phase
• A large number of operators with complex precedence and associativity rules
• Numerous control-flow mechanisms, some with complex semantics (such as goto, switch, for, break, continue, setjmp/longjmp, etc.)
• Implicit conversions that follow intricate rules
• Two types of comment markers that interact in a tricky way with line splicing (i.e., splitting logical lines into multiple physical lines using trailing backslashes as line-continuation markers).
The International Obfuscated C Code Contest, which has been running since 1984, awards a prize to the most obscure/obfuscated C programs that follow specific rules. As already mentioned, ensuring code readability and understandability is crucial for the effectiveness of code reviews and has an obvious impact on other program properties such as maintainability.

MISRA C

The MISRA,The Motor Industry Software Reliability Association, project was initiated in 1990 with the aim of providing best practice guidelines for the safe and secure development of both embedded control systems and standalone software. Originally, the project was part of the UK Government's "SafeIT" program but later it became self-supporting with MIRA Ltd, now HORIBA MIRA Ltd, providing the project management support. The core activities of MISRA include developing guidance in specific technical areas such as programming languages, model-based development, automatic code generation, software readiness for production, safety analysis, safety cases, and more. In November 1994, MISRA published its "Development guidelines for vehicle-based software," also known as "The MISRA Guidelines." This was the first automotive publication concerning functional safety, more than 10 years before work began on ISO 26262.

The MISRA guidelines prescribe the use of a restricted subset of a standardized structured language. As a response to this, the MISRA consortium started developing the MISRA C guidelines. At the time, Ford and Land Rover were each developing their own in-house rules for vehicle-based C software. It was recognized that creating a common set of guidelines would be more beneficial to the industry. The first version of the MISRA C guidelines was published in 1998 and it gained significant industrial attention.

In 2004, MISRA received numerous comments from its users, many of which were from non-automotive industries, surpassing their expectations. As a result, MISRA published an enhanced version of the C guidelines, specifically targeting all industries that develop C software for high-integrity and critical systems. The success of MISRA C prompted MISRA to release a set of MISRA C++ guidelines in 2008, as C++ is also used in critical contexts.

MISRA C:1998 and MISRA C:2004 are both guidelines that target the 1990 version of the C Standard. A revised set of guidelines called MISRA C:2012 was published in 2013, which supports both C99 and C90 (sometimes referred to as C95 in their amended and corrected form). Compared to the previous versions, MISRA C:2012 covers more language issues and provides a more precise specification of the guidelines with improved rationales and examples.

The "JSF Air Vehicle C++ Coding Standards for the System Development and Demonstration Program" had a significant impact on the development of coding standards for C++. This, in turn, led to the creation of MISRA C++:2008, which influenced the development of MISRA C:2012. The UK Ministry of Defence supported the development of the vulnerabilities document, which helped in identifying various behaviors in ISO C++. This document is similar to Annex J in ISO C, which is currently missing. Its absence makes it difficult to ensure that the guidelines are comprehensive. Additionally, MISRA C played a vital role in shaping NASA's "JPL Institutional Coding Standard for the C Programming Language" and other coding standards.

The MISRA C guidelines aim to enhance the safety and security of embedded or standalone systems. The guidelines define a subset of the C language that eliminates or minimizes the possibility of errors. They prohibit critical non-definite behavior and restrict the use of implementation-defined behavior and compiler extensions. Additionally, they control the use of language features that can be easily misused or misunderstood. Overall, the guidelines are designed to improve the reliability, readability, portability, and maintainability of the systems.

There are two kinds of MISRA C guidelines.

Directive: a guideline where the information concerning compliance is generally not fully contained in the source code: requirements, specifications, design, and etc. all may have to be taken into account. Static analysis tools may assist in checking compliance with respect to directives if provided with extra information not derivable from the source code.
Rule: a guideline where information concerning compliance is fully contained in the source code. Discounting undecidability, static analysis tools should, in principle, be capable of checking compliance with respect to the rule.

The MISRA C coding standard is intended to be used in conjunction with a documented development process, where any deviations from the standard that can be justified will be authorized and recorded. To make this process easier, each guideline in the MISRA C standard has been assigned a category.

Mandatory: C code that complies to MISRA C must comply with every mandatory guideline; deviation is not permitted.
Required: C code that complies to MISRA C shall comply with every required guideline; a formal deviation is required where this is not the case.
Advisory: these are recommendations that should be followed as far as is reasonably practical; formal deviation is not required, but non-compliances should be documented.

Organizations or projects have the option to treat required guidelines as mandatory and advisory guidelines as required or mandatory. Adopting MISRA Compliance:2016 allows advisory guidelines to be disregarded and marked as "Disapplied" when they are deemed to have no value, such as when adopted code has not been developed to comply with the MISRA C guidelines. However, the decision to disapply a guideline should not be taken lightly. It is important to create a guideline recategorization plan that includes the rationale for any decision to disapply a guideline.

MISRA C rules are categorized based on the amount of code that needs to be analyzed to detect all violations. Single Translation Unit refers to checking each translation unit independently. System requires checking more than the translation unit in question, if not all the source code that constitutes the system.

MISRA C:2012 Amendment 1 was published in 2016 to extend the applicability of MISRA C:2012 to industries and applications that prioritize data-security. It includes 14 new guidelines (1 directive and 13 rules) to complete the coverage of ISO/IEC TS 17961:2013, which is a set of rules for secure coding in C.

The coverage of the CERT C Coding Standard is almost complete with Amendment 1. As a result, MISRA C is the preferred language subset for all industries developing embedded systems in C that are safety- and/or security-critical.

Important Rules

MISRA established standards to ensure safe and reliable automotive software. Strict rules minimize risks and prevent vulnerabilities. We'll discuss critical rules for code clarity and safety adherence. Understanding them helps developers navigate the intricacies of software development.

Rule D.4.1 (required): Run-time failures shall be minimized

It is important to ensure that there are measures in place to detect and handle run-time errors. This is particularly crucial for safety-critical systems, as C language does not have built-in mechanisms to handle dynamic errors. Therefore, special attention is required to ensure the safety and reliability of such systems.
As a developer, it is important to keep a watchful eye on the occurrence of run-time errors while coding. To prevent such errors, checks should be introduced in the code wherever necessary, while also considering performance and code-size constraints. Below are some areas that should be taken into consideration, as they are prone to run-time errors.

Arithmetic Errors

These occur as the resultant of the evaluation of expressions giving rise to divide by zero error, overflow, or underflow scenarios.

{
num1 = 10;
for(i=0;i<10;i++)
{
result = num1/i; // Noncompliant
}

In the example, the literal i is initially initialized to zero; hence on dividing num1 by i, the zero division error is encountered with.

Pointer Arithmetic

This deals with the calculation of addresses where care must be taken to ensure that the addresses computed should be reasonable and point to places meaningful.

Left Shifts

Care must be taken while performing left shifts, as the Most Significant Bit is lost resulting in the overflow.

Array Bound Errors

The array indices while being used for indexing the array should be ensured that they are within the bounds specified.

Rule R.1.3 (required): There shall be no occurrence of undefined or critical unspecified behavior

The ISO standard specifies a minimum set of about 91 characters that all compilers must support. This means that even if a compiler supports a larger set of characters, only these 91 characters should be used. The standard has defined a set of escape sequences including \n, \t, \v, \b, \r, \f, \a, \\, ?, \', \", \[Octal Number], and \x[Hexadecimal Number] that can be used. It is important to note that using escape sequences other than these can lead to unpredictable behavior.

const char_t a[ 2 ] = "\k"; // Noncompliant
const char_t b[ 2 ] = "\b"; // Compliant

Rule D.4.1 (required): The character sequences /* and // shall not be used within a comment

The nesting of comments is not something that is supported in C. The comment starts on detecting /* and ends on the first occurrence of */ irrespective of any nesting of comments being attempted. A noncompliant code example supporting the rule statement is shown as follows.

/* This is a multi-line comment statement.
/* Nesting of comments leads to unexpected behavior*/
The actual comment ends here */

The example shows a multi-statement comment section which is begun with /*, but in the very next line, there is a comment line ending with */, whereas the actual comment ends in the next line. Now this might confuse the developer as which the actual ending of the comment might be, as the final line gets uncommented, due to the early detection of the */. Hence nesting of the comments is not used.

Rule R.7.1 (required): Octal constants should not be used

Any integer constant that begins with “0” (zero) is termed as an octal constant. The usage of the octal constants is denied, because this may cause ambiguous scenarios. Following example illustrates this rule. Consider a user who wants to assign fixed length integer constants to variables. The array initialization is done as follows.

data [0] = 500; /* set to decimal 500*/
data [1] = 071; /* set to decimal 57*/
data [2] = 520; /* set to decimal 520*/

In the code snippet, the user assigns the decimal value “071” to data, thinking that it would be taken in as an integer constant, but the compiler recognizes it as an octal value as it has begun with a “0” and hence assigns the decimal value of the octal constant “071” which is “57” to data. Therefore it is better not to use octal constants, yet zero is an exception as it holds the same value even in the octal representation.

Rule R.8.1 (required): Types shall be explicitly specified

Implicit typing of variables and functions though supported by some C compilers shall not be used according to the rule, as it might lead to confusions. A supporting example shows a noncompliant form of the rule along with its compliant solution in the comments is shown as follows.

extern x; // Compliant solution - extern int16_t x;
const x; // Compliant solution - const int16_t x;
static fun(void); // Compliant solution - static int16_t fun(void);

Rule R.9.1 (required): The value of an object with automatic storage duration shall not be read before it has been set

Normally when the integer variable is declared without any storage specifier, the default specifier it takes is, the auto class. These integer variables shall not be used before getting initialized, to avoid any unexpected behavior due to garbage values. In the example below the variable data returned by the function would hold garbage value, due to the conditional construct, as it is not initialized before being used.

{
int data, value;
value=0;
if (value==1)
{
data = 45;
}
return data;
}

The intention of this rule is that all the variables have to be initialized before being used. The initialization need not necessarily be done at the time of the declaration but at some other part of the code but before the variable is put into use.

Rule R.10.1 (required): Operands shall not be of an inappropriate essential type

There are rules that are to be followed on using the operators over the operands. One such is the rule that talks about the usage of the Bitwise operator over its operands. The built-in Bitwise operators (~, >>, >>=, &, &=, ^, ^=, |, and |=), if used on the signed integer constants, yield implementation-dependent results. The most significant of them is the left shift which, if performed on the signed integers, may cause the signed bit, which is the Most Significant Bit, to be lost in the process, which leads to erroneous results. Hence, the bitwise operators are not used against the signed integers. A supporting illustration is shown as follows.

if ((uint16_value & int16_data) == 0x246U)
if (~int16_data == 0x246U)

The example shows a bitwise operation being performed between an unsigned and a signed integer and another bitwise operation being performed on a signed integer. Both of these operations might yield results far from the unexpected one.

Rule R.11.3 (required): A cast shall not be performed between a pointer to object type and a pointer to a different object type

Rule R.11.3 (required): A conversion should not be performed between a pointer to object and an integer type

These rules are extracted from a set of rules that talk about conversions from one type to another. These rules in particular talk about things that have to be kept in mind while dealing with pointers and conversions. Pointer types shall neither be made to cast into other types nor other types be cast into pointers. It is because if an address value being held by a pointer variable is assigned to an integer variable, it not be able to hold the complete value of the address due to its size. In this case, there occurs data loss, and further computations involving these variables will not yield the expected results. An example supporting this rule is shown.

int* data;
int addr_value = (int) &data;

The example shows a pointer data variable being type cast into an integer and its value being assigned to an integer value. Data loss may occur if the addr_value is not large enough to accommodate the address value being assigned to it.

Rule R.12.1 (advisory): The precedence of operators within expressions should be made explicit

This rule is from the set of rules that are designed to be followed for evaluating or forming an expression for evaluation. Precedence is normally followed for the evaluation of an expression to arrive at the intended result. But the rules of precedence can be confusing at times. Hence in order to avoid this confusion which may cause unpredictable results later, it is advisable to have a limited dependency on the rules of precedence. The expression can be evaluated according to the precedence by making use of parentheses, in case of complex statements. However, there should not be overusing of the parentheses. A noncompliant code example is shown.

x = a == b ? a : a - b; // Noncompliant; Compliant Usage -> x = ( a == b ) ? a : ( a - b );
x = a + b - c + d; // Noncompliant; Compliant Usage -> x = ( a + b ) - ( c + d );
x = a * 3 + c + d; // Noncompliant; Compliant Usage -> x = ( a * 3 ) + c + d;

Rule R.16.3 (required): An unconditional break statement shall terminate every switch clause

Rule R.16.4 (required): Every switch statement shall have a default label

Rule R.16.5 (required): A default label shall appear as either the first or the last switch label of a switch statement

Rule R.16.6 (required): Every switch statement shall have at least two switch clauses

Rule R.16.7 (required): A switch expression shall not have essentially Boolean type

These are few rules to be followed while writing a switch statement. The switch cases inclusive of the default case mark their end when an unconditional break statement is introduced. The usage of the break statement is permitted only in the
case of a switch statement, and an exception exists in case of an empty case clause. The switch statement should have a default label which can be present either at the end or at the top under a switch statement. The switch expression is prohibited in using a Boolean type, as the result of a Boolean computation is either true (1) or false (0), in which case a simple if…else construct would suffice as there would be only two choices to decide upon. Hence switch statements are expected to have at least two cases to prove their usage. These are illustrated in example.

switch (value) /* value is not of type Boolean*/
{
  case 0:
    statement 1;
    break; /* break statement is required after the case statements*/
  case 1: /* empty case clause, no break is required*/
  case 2:
    statement 1;
    break;
  default:
    err_flag_count = 1;
    break;
}

Rule R.17.2 (required): Functions shall not call themselves, either directly or indirectly.

Recursive functions are not considered to be used in case of safety-critical systems. This is because the usage of the recursive functions consumes the stack space and causes the danger of depleting the same. The recursive function requires high control, else it would not be possible to determine the worst-case stack usage. A supporting noncompliant code example is shown.

void func()
{
  printf("This is a recursive function");
  func(); //Noncompliant
}

Rule R.9.5 (required): Where designated initializers are used to initialize an array object, the size of the array shall be specified explicitly

The declaration of an array without specifying the size of the array is possible. But it is not allowed according to the rules, as that might be unclear. An illustration on this is shown.

int arr1 [ ];
int arr2 [ ] = { [0] = 1, [12] = 36, [4] = 93 };
int pirate [ ] = { 2, 4, 8, 42, 501, 90210, 7, 1776 }

In the example, all the lines of array declaration are noncompliant as the size of the array is not specified explicitly. In the second line of declaration, the highest size defines the size implicitly, and in the third line, the total number of items defines the size, but these implicit declarations of size might be unclear, hence not used according to the rule.

Rule R.19.2 (advisory): The union keyword should not be used

The usage of union in order to access an object in different ways may cause mis-interpretation of the data. Hence this rule was designed to prevent the usage of unions in any circumstances. An example of a noncompliant code is shown.

union U1 // Noncompliant
{ 
  float j;
  int i;
}

Rule R.20.4 (required): A macro shall not be defined with the same name as a keyword

The reserved identifiers, function, and macros that come under the standard library should not be defined or undefined or redefined. The names of the standard library macros, functions, and objects are prohibited to be reused. An example illustration is discussed.

#define sqrt cathy

In the example, the library function sqrt is being redefined, such that wherever the keyword sqrt occurs in the code, the pre-processor is instructed to just replace the same with the value “cathy,” where in a real case, the library function sqrt comes under the “math library” and is used to compute the square root of a given number.

Tools and Checkers

Static analysis is an essential part of the software development process that involves the automatic examination of source code without executing the application. It is an effective technique that can help to identify potential errors, security vulnerabilities, and other defects in the code, thus improving the quality and reliability of embedded software. For embedded software, there are various types of static analysis techniques that can be employed to detect different types of issues:

Control flow analysis: This type of analysis checks the control flow of the code to identify potential errors, such as unreachable code and infinite loops.
Data flow analysis: This type of analysis checks the flow of data through the code to identify potential errors, such as data races and memory leaks.
Pointer analysis: This type of analysis checks the use of pointers in the code to identify potential errors, such as dangling pointers and buffer overflows.
Security analysis: This type of analysis checks the code for potential security vulnerabilities, such as buffer overflows and SQL injection.
Compliance analysis: This type of analysis checks the code for compliance with a specific standard, such as MISRA C or DO-178B.

Automated tools can scan C codebase for MISRA C violations, generating detailed reports on potential issues and their locations.

LDRA Tool Suite (proprietary)

The LDRA Tool Suite is a software analysis tool from LDRA that provides automated testing, static analysis, and dynamic testing capabilities. It includes MISRA C compliance checking and helps ensure the safety and reliability of embedded systems software.

Parasoft C/C++test (proprietary)

This tool offers robust MISRA C support, including rule checking, automated reporting, and integration with development environments. It can identify coding practices that might not strictly violate the standard but could introduce maintainability or safety concerns.

PC-lint Plus (proprietary)

PC-lint Plus comes with a comprehensive rule set covering widely recognized coding standards such as MISRA, CERT-C and AUTOSAR. With an unparalleled focus on seamless integration and automation, PC-lint Plus stands out as the definitive solution for consistent, reliable, and superior quality C and C++ source code analysis.

Cppcheck (free software/open source)

It provides unique code analysis to detect bugs and focuses on detecting undefined behaviour and dangerous coding constructs. The goal is to have very few false positives. Cppcheck covers almost all the MISRA C 2012 rules. Including the amendments. Together with a C compiler you get full coverage.

References

van der Linden, P. (1994). Expert C Programming. Prentice Hall.
Bagnara, R., Bagnara, A., & Hill, P. M. (2019). The MISRA C coding standard: A key enabler for the development of safety-and security-critical embedded software. In embedded world Conference 2019—Proceedings (pp. 543-553).
MISRA, MISRA C:2012 Addendum 2 (2018)— Coverage of MISRA C:2012 (including Amendment 1) against ISO/IEC TS 17961:2013 “C Secure”, 2nd ed. Nuneaton, Warwickshire CV10 0TU, UK: HORIBA MIRA Ltd.
Yamili, Y. C., & Kathiresh, M. (2021). Autosar and misra coding standards. In Automotive Embedded Systems: Key Technologies, Innovations, and Applications (pp. 37-70). Cham: Springer International Publishing.

Immutable Linux

Amin Khozaei — Thu, 07 Mar 2024 17:52:55 +0000

Embracing Immutable Architecture

In the constantly evolving world of software engineering, traditional mutable systems have long faced challenges that hindered their stability, security, and scalability. These challenges have paved the way for a groundbreaking approach: immutable architecture. This paradigm shift offers a robust solution to age-old problems, revolutionizing how we design and manage complex systems, particularly in the realm of Linux distributions and containerized environments.

Challenges of Mutable Systems

Mutable systems, characterized by their ability to modify the core system, have historically faced several hurdles:

Unproducible Environments: In mutable systems, manual configurations often varied across environments, leading to inconsistencies that could result in bugs and errors during development, testing, or deployment.
Configuration Drift: Over time, configurations on mutable systems could deviate from their intended state due to multiple users and administrators making changes. This drift introduced inconsistencies and vulnerabilities, challenging system stability and security.
Security Vulnerabilities: Providing write access to system files in mutable systems exposed them to exploitation by malware or human error. Even accidental modifications could compromise system integrity and introduce instability.
Difficulty in Rollback: Recovering from a faulty configuration or update in mutable systems proved complex, as changes were incremental and intertwined. Rolling back to a known good state often required manual intervention, carrying the risk of further unintended modifications.

The Immutable Solution

In response to these challenges, immutable architectures emerged, offering a paradigm shift in system design:

Maintaining a Read-Only Core System: Immutable architectures ensure system stability and security by maintaining a read-only core system. This prevents accidental or malicious modifications, enhancing overall system integrity.
Atomic Updates: Updates are applied atomically, deploying new versions of the system as complete, self-contained images. This ensures consistency and avoids partial updates that could lead to issues or vulnerabilities.
Leveraging Containerization: Immutable architectures often leverage containerization, where applications run in isolated containers. This further enhances security and prevents conflicts or dependencies on the core system.

Benefits of Immutable Architecture

Immutable architecture brings a plethora of benefits to the table:

Enhanced Security and Stability: By eliminating direct modifications and enforcing a read-only core system, immutable architectures enhance security and stability, minimizing the attack surface and reducing the risk of configuration drifts.
Predictable Environments: With immutable architectures, environments are reproducible and consistent, making it easier to predict system behavior and reason about the impact of changes.
Simplified Rollback and Recovery: Recovering from issues or failures becomes simpler with immutable architectures, as deploying a known good version involves swapping to a previous, verified state, reducing downtime and minimizing operational overhead.

Applications and Considerations

Immutable architectures find application across various domains:

Linux Distributions: Many modern Linux distributions have embraced immutable architectures for their base systems, deploying new images instead of modifying existing ones to enhance security and consistency.
Containerized Applications: Containerized applications, prevalent in platforms like Docker and Kubernetes, inherently follow immutable principles, promoting faster deployments and simplified management.

Immutable Linux Distributions

An immutable Linux distribution is a type of operating system that adheres to the principle of immutability, where the core components of the system, including the root file system, are designed to be read-only and cannot be modified after the system has been deployed. Immutable Linux distributions offer a unique approach to system design and management, emphasizing security, reliability, and consistency.

Read-Only Root File System

Traditional Linux distributions follow a mutable approach in which the core system, residing in the root filesystem, is writable. This approach allows for modifications, installations, and configurations, but it comes with inherent risks and complexities. Immutable distributions challenge this paradigm by adopting a read-only root filesystem, offering several key advantages:

Enhanced Security: By preventing direct modifications to critical system files, the attack surface for malware and human error shrinks significantly. This significantly reduces the risk of vulnerabilities and breaches.
Improved System Stability: The read-only nature ensures the core system remains in a known good state, eliminating the possibility of accidental modifications or configuration drift that can destabilize the system.
Faster Rollbacks: If an update introduces issues, reverting to the previous version is much simpler. The old system remains untouched, allowing a quick switch back to minimize downtime.
Greater Consistency: All systems deployed from the same image share an identical root filesystem, ensuring consistency and predictability across environments.

While the core system in an immutable Linux distribution resides in a read-only root filesystem, there are often exceptions made for specific directories:

/etc: This directory typically houses configuration files for various applications and services. While immutability aims to minimize configuration drift, allowing modifications to /etc enables customization within a controlled environment. Some distributions utilize a writable overlay layer specifically for /etc, allowing changes to persist across reboots.
/var: This directory stores variable data, such as logs, temporary files, and caches. Since this data is constantly changing, it necessitates a writable location. However, some distributions might employ techniques like layering or dedicated writable partitions to manage /var within the context of immutability.
/home: This directory stores user data like documents, configurations, and application settings. Maintaining user data across updates is crucial, and /home needs to be writable for users to access and modify their files. Some distributions might place /home on a separate writable partition or utilize a dedicated writable overlay layer.

Atomic Updates and Rollbacks: The Power of Reverting in Immutable Linux

Immutable Linux distributions, with their read-only root filesystems, prioritize security and stability. Updates, however, can introduce unforeseen issues. Here's where atomic updates and rollbacks shine. These features ensure seamless transitions during updates and provide a safety net for quick recovery if needed.

The Power of Atomicity: All or Nothing

Imagine a complex system update like a delicate surgery. One wrong move during the operation can have disastrous consequences. Similarly, traditional updates can leave the system in an inconsistent state if something goes wrong midway. Atomic updates address this by guaranteeing the entire update process happens as a single, indivisible unit. In the context of immutable systems, atomicity ensures either the entire update succeeds or the system remains unchanged.
Here's a breakdown of atomic updates:

New Image Creation: A complete system image, containing the updated files and configurations, is built.
Deployment: The new image is deployed alongside the existing system. This doesn't affect the running system yet.
Testing and Validation: Rigorous testing verifies the new system functions correctly before switching over.
Atomic Switch: If all goes well, a swift transition occurs, completely replacing the running system with the new image. This switch is atomic, meaning either the entire update succeeds, or the system remains unchanged.

Undoing Mistakes: The Rollback Magic

One of the main advantages of immutability is that it allows for easy rollback in case updates go wrong. If an update fails, the system can be quickly restored to a previous working state. Rollbacks function in the following way:

Switching Back: Since the previous system image remains untouched, simply switching back to it effectively rolls back the update. This is analogous to reverting a database transaction that encountered an error.
Minimal Downtime: Rollbacks are typically fast, minimizing downtime and ensuring service continuity. This is crucial for production environments.

Approaches to Achieve Atomicity and Rollbacks

Several techniques exist for implementing atomic updates and rollbacks in immutable distributions. Here's a look at three common approaches:

libostree: This library, used by Fedora CoreOS and Silverblue, leverages a layered filesystem approach. It manages updates by creating new, read-only layers on top of the existing ones. Updates are atomic because either the entire new layer is successfully applied, or the previous state remains untouched. Rollbacks involve simply switching back to the previous layer, similar to undoing a database transaction.
A/B Partitioning: This approach, used by RancherOS, utilizes two separate partitions for the root filesystem. One partition is active, while the other remains inactive. During an update, the new system image is written to the inactive partition. Once testing is complete, a quick switch activates the updated partition, effectively rolling out the update. In case of issues, the system can simply boot from the original, known good partition. This method mirrors a database transaction by preparing changes in a separate space before applying them to the main system.
Snapshot-based Systems: Some distributions like SUSE MicroOS use tools like Btrfs snapshots to create a point-in-time copy of the system before applying updates. This snapshot acts as a rollback point. If the update fails, the system can revert to the previous snapshot. Snapshotting offers a more lightweight alternative to full image-based approaches.

Automated Updates

Immutable Linux distributions, with their read-only root filesystems, prioritize security and stability. However, manually managing updates on numerous systems can be time-consuming and prone to errors. Here's where unattended updates and scheduled updates come in, offering automation to keep your systems up-to-date and secure.

Unattended Updates

Unattended updates allow you to configure your immutable system to automatically download and install new system images containing the latest updates. This eliminates the need for manual intervention and ensures your systems are always running the most recent and secure versions. Here are some key points about unattended updates:

Configuration Options: Most distributions provide configuration options to define update behavior, such as specifying update frequency (daily, weekly, etc.) and defining a window for applying updates (outside peak usage hours for minimal disruption).
Dependency Management: Update systems in immutable distributions typically handle dependency management automatically. Since new images are complete units, any dependencies required by the updates are already included.
Testing and Validation: While updates happen automatically, some distributions might offer pre-testing options. You can test a new image in a controlled environment before deploying it to production systems.

Scheduled Updates

Scheduled updates further enhance the automation capabilities. You can define specific times for updates to occur, ensuring they happen at your convenience and minimize disruption to critical workloads. Here's what you need to know about scheduled updates:

Flexibility: Schedule updates to occur during off-peak hours or maintenance windows to minimize impact on running applications.
Predictability: Scheduled updates provide predictability in your update cycle, allowing you to plan system downtime and maintenance activities accordingly.
Integration with Management Tools: Many distributions offer integration with system management tools like Ansible or Puppet. These tools can be used to automate the entire update process, including scheduling and triggering rollbacks if necessary.

Reverting to Stability

Even with automated updates, unforeseen issues can arise. The beauty of immutable systems lies in their ability to easily rollback to a previous state. Here's how rollbacks work in the context of unattended and scheduled updates:

Rollback Options: Most distributions provide tools or configuration options to trigger a rollback if an update introduces problems.
Immutable History: Since previous system images remain untouched, a rollback simply involves switching back to the previously deployed image. This ensures a quick and efficient recovery process.
Minimal Downtime: Rollbacks are typically fast, minimizing downtime and ensuring service continuity for your applications.

Declarative Configuration

Traditional configuration management often involves editing text files directly on the system. This can be error-prone and time-consuming, especially for complex configurations. In contrast, declarative configuration focuses on what the desired state is, rather than how to achieve it.

Here's a breakdown of the key differences:

Imperative (Traditional): Focuses on the specific steps or commands needed to achieve the desired configuration. This approach can be complex and error-prone, especially for intricate configurations.
Declarative: Describes the desired state of the system in a human-readable format. The configuration tool then takes care of interpreting the desired state and making the necessary changes to achieve it. This approach is more concise and less error-prone.

Declarative configuration offers several advantages in the context of immutable systems:

Repeatability and Consistency: Configurations are defined in reusable files, ensuring consistent system state across multiple deployments. This is crucial for maintaining identical environments.
Human-Readable: Configuration files are easier to understand and maintain compared to editing raw system files directly. This simplifies collaboration and troubleshooting.
Idempotence: A key principle of declarative configuration is idempotence. This means that running the configuration multiple times will result in the same desired state, even if the system state has already been achieved. This prevents accidental configuration drift and ensures consistency.
Version Control: Configuration files can be version controlled, allowing you to track changes and revert to previous configurations if needed. This enhances rollback capabilities and facilitates auditing.

Several tools are commonly used for declarative configuration management in immutable Linux distributions:

Ansible: A powerful tool offering a YAML-based language to define configurations. It can manage configurations across multiple systems and platforms.
SaltStack: Another popular option with a declarative language and a focus on automation and orchestration.
Chef: A mature tool with a Ruby-based language for configuration management. While not as widely used in immutable deployments, it's still a viable option in some cases.

While declarative configuration management tools play a significant role in managing immutable Linux distributions, some distributions also offer APIs as an alternative or complementary approach.

Conclusion

While immutable architecture offers significant advantages, it's essential to consider potential trade-offs, such as reduced flexibility and increased operational overhead, particularly in comparison to mutable systems. However, for environments where security, reliability, and ease of rollback are paramount, immutable architecture emerges as a powerful tool for building resilient and scalable systems.

As the tech landscape continues to evolve, understanding and embracing immutable architecture can be a transformative step in navigating the complexities of modern software development and deployment. By building on a foundation of immutability, organizations can pave the way for more resilient, secure, and efficient systems, poised to thrive in an ever-changing digital landscape.

References

Perry, M. L. (2020). The Art of Immutable Architecture. Apress.

What is Xenomai?

Amin Khozaei — Wed, 28 Feb 2024 15:45:06 +0000

Understanding Hard, Firm, and Soft Real-Time Systems

Real-time systems are often classified based on the strictness of their timing requirements. Here are the three main classifications:

Hard Real-Time Systems:
- Hard real-time systems have strict timing constraints where missing a deadline is considered catastrophic and unacceptable.
- In hard real-time systems, the correctness of the system's behavior depends not only on the logical result of computations but also on the time at which the results are produced.
- Examples of hard real-time systems include flight control systems, medical devices such as pacemakers, and automotive safety systems like anti-lock brakes.
Firm Real-Time Systems:
- Firm real-time systems also have strict timing requirements, but occasional deadline misses can be tolerated as long as they happen infrequently and the system can still maintain its overall usefulness.
- In firm real-time systems, missing deadlines might result in a degradation of system performance but not catastrophic failure.
- Examples of firm real-time systems include multimedia streaming applications where occasional frame drops or delays are tolerable but should be minimized to maintain user experience.
Soft Real-Time Systems:
- Soft real-time systems have timing constraints, but missing deadlines does not necessarily lead to system failure or significant degradation in system performance.
- In soft real-time systems, meeting deadlines is desirable but not mandatory. The system can still provide useful results even if deadlines are occasionally missed.
- Examples of soft real-time systems include online video conferencing applications, where a slight delay in transmitting audio or video data may be acceptable as long as the overall communication remains effective.

Real time is the time it takes for an action to have a noticeable effect. (Paul Graham)

Predictable System Challenges

The focus on computer system architecture design is often to improve the performance for general-purpose use, which does not include a strict requirement of timing.

Predictable system challenges such as CPU pipeline, cache, multi-threading, and multi-core play crucial roles in determining the predictability and performance of real-time systems. Here's a brief description of each:

CPU Pipeline:
- The CPU pipeline is a fundamental component of modern processors that allows them to execute multiple instructions concurrently by breaking down instruction execution into multiple stages.
- While pipeline architectures improve instruction throughput and overall performance, they can introduce challenges for real-time systems due to potential pipeline stalls, dependencies, and branch prediction errors that can lead to unpredictable execution times.
- Real-time systems need to carefully manage pipeline hazards to ensure predictable behavior and meet timing constraints.
Cache:
- Caches are small, high-speed memory units located on or near the CPU that store frequently accessed data and instructions to reduce access latency and improve performance.
- While caches significantly enhance system performance for non-real-time applications by reducing memory access times, they can introduce unpredictability in real-time systems due to cache misses, cache coherence issues, and the non-deterministic nature of cache replacement policies.
- Real-time systems must employ cache management techniques such as cache partitioning, cache locking, and cache-aware scheduling to control cache behavior and maintain predictability.
Multi-threading:
- Multi-threading enables concurrent execution of multiple threads within a single process, allowing programs to utilize CPU resources more efficiently and improve responsiveness.
- However, multi-threading introduces challenges for real-time systems, including thread scheduling overhead, priority inversion, and contention for shared resources such as CPU cores, memory, and I/O devices.
- Real-time systems need to implement thread scheduling policies that prioritize critical tasks, minimize thread interference, and prevent priority inversion to ensure timely execution of tasks and meet deadlines.
Multi-Core:
- Multi-core processors integrate multiple CPU cores on a single chip, enabling parallel execution of tasks and higher overall system throughput.
- While multi-core architectures offer increased computational power and scalability, they pose challenges for real-time systems in terms of task allocation, load balancing, and inter-core communication.
- Real-time systems must employ efficient task scheduling and synchronization mechanisms to leverage the benefits of multi-core processors while maintaining predictability and meeting timing constraints.

Real-Time Operating System

A real-time operating system (RTOS) serves as a critical intermediary layer between application software and hardware components in embedded systems and other time-critical environments. One of the primary functions of an RTOS is to abstract and manage hardware resources efficiently, shielding application developers from the intricacies of low-level hardware interaction. This abstraction allows developers to focus on implementing the desired functionality of their applications without needing to delve deeply into the specifics of the underlying hardware platform.

RTOSs achieve this abstraction by providing a set of standardized interfaces and services for accessing hardware resources such as CPU processing time, memory, I/O devices, and communication interfaces. These interfaces typically include system calls, device drivers, and middleware components that enable developers to interact with hardware resources in a platform-independent and programmer-friendly manner.

By encapsulating hardware details and providing a unified programming interface, RTOSs enable application developers to write portable and scalable code that can be easily adapted to different hardware platforms with minimal effort. This abstraction also promotes code reusability and maintainability, as developers can focus on writing application logic without being tied to specific hardware implementations.

Additionally, RTOSs are designed to minimize overhead and maximize system efficiency to meet the stringent timing requirements of real-time applications. Unlike general-purpose operating systems (GPOS), which may prioritize features such as multitasking, multi-user support, and graphical user interfaces, RTOSs are optimized for low-latency, deterministic operation.

RTOSs achieve low overhead by employing lightweight task scheduling algorithms, efficient memory management strategies, and streamlined kernel designs. These optimizations reduce context switching times, minimize memory footprint, and ensure rapid response to system events, enabling real-time applications to meet their timing constraints reliably.

Moreover, the reduced overhead of RTOSs translates into lower system costs and improved predictability for embedded systems and other resource-constrained environments. By minimizing unnecessary computational overhead and resource contention, RTOSs enable developers to achieve higher performance and tighter control over system behavior, leading to more efficient utilization of hardware resources and reduced development costs.

Linux

Linux is one of the most widely used general-purpose operating systems (GPOS) in the world. Originally developed as a hobby project by Linus Torvalds in the early 1990s, Linux has since evolved into a powerful and versatile operating system that powers a vast array of computing devices, from personal computers and servers to embedded systems and supercomputers.

As a general-purpose operating system, Linux is designed to provide a rich set of features and functionalities to support a wide range of computing tasks and applications. However, while Linux excels as a general-purpose operating system, it is not typically used in scenarios requiring real-time capabilities. Real-time operating systems (RTOS) like VxWorks, FreeRTOS, or QNX are specifically designed to provide deterministic behavior and meet strict timing constraints, which are essential for real-time applications such as industrial control systems, automotive electronics, and medical devices.

Linux, in contrast, is optimized for general-purpose computing tasks where determinism and timing guarantees are not critical. While efforts have been made to improve Linux's real-time capabilities through technologies like the PREEMPT-RT patch, it may still not be suitable for applications with ultra-low-latency or hard real-time requirements.

Real-Time Linux

In the realm of real-time computing, achieving precise timing guarantees and deterministic behavior is paramount for applications operating in time-critical environments. Linux, a versatile and widely used general-purpose operating system, has garnered attention as a platform for real-time applications despite its non-deterministic nature. Two prominent approaches have emerged to augment Linux with real-time capabilities: the single kernel approach with the PREEMPT-RT patch and the dual kernel approach with Xenomai. Each approach offers distinct methodologies for providing real-time responsiveness within the Linux ecosystem, catering to a diverse range of real-time application requirements.

Single Kernel Approach with PREEMPT-RT

In the single kernel approach, real-time capabilities are added to the Linux kernel through the PREEMPT-RT patch. This patch modifies the Linux kernel to reduce latency and improve responsiveness, making it more suitable for real-time applications. Some key features and characteristics of the PREEMPT-RT approach include:

Preemption: The PREEMPT-RT patch enables full preemption of the Linux kernel, allowing higher-priority tasks to preempt lower-priority tasks even during critical sections of code execution. This reduces latency and improves the responsiveness of real-time tasks.
Interrupt Handling: Interrupt handling in the Linux kernel is optimized to minimize interrupt latency, ensuring timely response to external events. This is crucial for real-time applications that rely on rapid event handling and precise timing.
Scheduler Enhancements: The Linux scheduler is modified to support priority-based scheduling algorithms that prioritize real-time tasks over non-real-time tasks. This ensures that critical tasks are executed in a timely manner and meet their deadlines.
Determinism: While the PREEMPT-RT patch improves the real-time capabilities of the Linux kernel, it may not provide the strict determinism required for certain real-time applications with ultra-low-latency or hard real-time requirements. However, it offers significantly improved real-time performance compared to the vanilla Linux kernel.
Single Kernel: In the single kernel approach, real-time tasks and non-real-time tasks share the same Linux kernel, providing a unified execution environment for both types of applications.

Dual Kernel Approach with Xenomai

In the dual kernel approach, real-time capabilities are provided by a separate real-time microkernel running alongside the Linux kernel. Xenomai is one such real-time microkernel that operates in parallel with Linux, providing deterministic behavior and strict timing guarantees for real-time tasks. Here are some key aspects of the Xenomai approach:

Separation of Concerns: Xenomai operates as a separate real-time executive (Xenomai nucleus) running alongside the Linux kernel. Real-time tasks are executed within the Xenomai environment, while non-real-time tasks continue to run within the Linux environment. This separation ensures that real-time tasks are shielded from non-real-time activities and can meet their timing requirements reliably.
Determinism: Xenomai provides strict determinism and precise timing guarantees for real-time tasks by implementing priority-based scheduling algorithms, minimal interrupt latency, and efficient inter-task communication mechanisms. This makes it suitable for applications with hard real-time requirements.
Interrupt Handling: Interrupts are efficiently managed within the Xenomai environment to minimize interrupt latency and ensure timely response to external events. Xenomai provides mechanisms for prioritizing interrupt handling and preempting lower-priority tasks when necessary.
Linux Compatibility: Xenomai is designed to be compatible with the Linux ecosystem, allowing real-time tasks to interact with Linux services and device drivers seamlessly. This enables developers to leverage existing Linux infrastructure and libraries while developing real-time applications.
Dual Kernel Architecture: In the dual kernel approach, the Linux kernel and Xenomai nucleus operate as separate entities, each managing its own set of resources and tasks. This architecture provides a clear separation of concerns between real-time and non-real-time activities, ensuring that real-time tasks can execute predictably without being affected by non-real-time activities.

Xenomai

Xenomai is a real-time development framework designed for Linux-based systems, enabling the creation of applications with strict timing requirements. It employs a dual kernel architecture, comprising a small real-time microkernel called the Xenomai nucleus, which runs alongside the Linux kernel. This separation ensures that real-time tasks can execute independently of non-real-time tasks, providing deterministic behavior and precise timing guarantees.

I-pipe

The Interrupt Pipeline (I-pipe) is a technology used by Xenomai to enable coexistence between the Linux kernel and the Xenomai nucleus. The I-pipe intercepts and handles interrupts before they reach the Linux kernel, allowing Xenomai to provide deterministic interrupt handling and low-latency response times.

Dovetail

Dovetail is a component of Xenomai that facilitates the integration between the Linux kernel and the Xenomai nucleus. It provides mechanisms for coordinating interrupt handling, scheduling, and resource management between the two kernels, ensuring compatibility and seamless operation.

Emulated Virtualization Layer (EVL)

A recent addition to Xenomai is the Emulated Virtualization Layer (EVL), which virtualizes real-time services within the Linux kernel context. EVL aims to provide a lightweight and efficient real-time execution environment by leveraging modern Linux kernel features and hardware capabilities. It enables real-time tasks to execute directly within the Linux kernel while maintaining strict determinism and low-latency performance.

A program that implemented by Xenomai is like the image below:

References:

Liu, J. W. S. (2000). Real-Time Systems. Prentice Hall.
Laplante, P. A. (2011). Real-Time Systems Design and Analysis: Tools for the Practitioner. Wiley-IEEE Press.
Xenomai. (2023). Overview. Retrieved from https://v4.xenomai.org/overview/

Conan by example for C

Amin Khozaei — Thu, 29 Jun 2023 19:59:27 +0000

As a C developer, you know that many tools exist for managing projects. Every C projects use a subset of these tools, so if you want to use a C library in your project, you should understand how these tools work. If you choose CMake as the build generator of your project, and you want to use a library that uses different build tools like Autotools, you should know how to use Autotools in your CMake file. Conan supports multiple build generators and makes suitable configs based on desired build generator. So, you could select each library that exists in Conan repositories.
Conan can do more things like:
It is fully decentralized. Users can host their packages on their servers, privately. Integrates with Artifactory and Bintray.
Portable. Works across all platforms, including Linux, OSX, Windows, Solaris, FreeBSD, embedded and cross-compiling, docker, WSL
Manage binaries. It can create, upload and download binaries for any configuration and platform, even cross-compiling, saving lots of time in development and continuous integration. The binary compatibility can be configured and customized. Manage all your artifacts in the same way on all platforms.
Integrates with any build system, including any proprietary and custom one. Provides tested support for major build systems (CMake, MSBuild, Makefiles, Meson, etc).
Extensible: Its Python-based recipes, together with extension points allow for great power and flexibility.
Stable. Used in production by many companies, since 1.0 there is a commitment not to break package recipes and documented behavior.
Read more on its homepage or GitHub.

How to install Conan

Python 3.6 or newer is required to install Conan tool. The following commands should run to install it.

pip install conan
conan profile detect

‍‍
If you have installed toolchains, the output of recent command is like:

gcc>=5, using the major as version
gcc C++ standard library: libstdc++11
Detected profile:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux

WARN: This profile is a guess of your environment, please check it.
WARN: The output of this command is not guaranteed to be stable and can change in future Conan versions.
WARN: Use your own profile files for stability.
Saving detected profile to /home/amin/.conan2/profiles/default

Conan supports http and https proxies. If you want to config proxy, the following variables in GNU/Linux should be set.

export HTTP_PROXY="http://ip:port"
export HTTPS_PROXY="http://ip:port"

Using Conan

Libraries in the main repository could be accessed by conan.io or by conan search <libname>. After finding the suitable version of each library, the Conan config file should be configured. Conan supports two different config styles, conanfile.py which uses Python to config Conan tool, and conanfile.txt which has ini style.

An example is a cli software that gets some options and makes a decision on each option.

[requires]
glib/2.73.0

[generators]
CMakeDeps
CMakeToolchain

[options]
glib*:shared=False

The conanfile.txt has multiple sections, requires section used to define imported libraries with specific version, generator section used to define your project's generator like CMake, and options section used to config each imported library, for example, glib*:shared=False used to compile glib statically. Now it's time to create CMakefile.txt. Here is the content of CMakefile.txt.

cmake_minimum_required(VERSION 3.22.6)
project(net_alert C)

find_package(glib REQUIRED)

include_directories(include)

add_executable(${PROJECT_NAME} src/main.c )

target_link_libraries(${PROJECT_NAME} glib::glib-2.0)
target_link_libraries(${PROJECT_NAME} glib::gio-2.0)

Conan makes cmake presets for each library, so find_package can find the library. target_link_libraries should be used to link with our example. Here is the example code.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <glib.h>
#include <glib/gi18n.h>
#include <gio/gio.h>
static struct config_s {
    gint server_port;
    GString server_ip;
    gboolean server_mode;
    GString wav;
    GString command;
}config;

GString *gbuffer;

static GOptionEntry entries[] =
{
  { "port", 'p', 0, G_OPTION_ARG_INT, &config.server_port, "Server_port", NULL },
  { "destination", 'd', 0, G_OPTION_ARG_STRING, &config.server_ip, "Server ip address", NULL },
  { "server", 's', 0, G_OPTION_ARG_NONE, &config.server_mode, "Server mode", NULL },
  { "wav", 'w', 0, G_OPTION_ARG_STRING, &config.wav, "WAV alert file", NULL },
  { "command", 'c', 0, G_OPTION_ARG_STRING, &config.command, "Command to send to the server", NULL },
  { NULL }
};

int
main(int argc, char **argv) {
    GError *error;
    GOptionContext *context;

    error = NULL;
    wav = g_string_new("alert.wav");
    config.server_mode = FALSE;
    config.server_port = 2986;
    gbuffer = g_string_new(NULL);
    context = g_option_context_new ("net_alert: an application to alert on demand");
    g_option_context_add_main_entries (context, entries, NULL);
    g_option_context_add_group (context, NULL);//gtk_get_option_group (TRUE));
    if (!g_option_context_parse (context, &argc, &argv, &error)){
        g_print("option parsing failed: %s\n", error->message);
        exit(EXIT_FAILURE);
    }
    g_string_overwrite(wav, 0, config.wav.str);
    printf("port: %i\nserver address: %s\nserver mode: %i\nWav: %s\ncommand: %s\n\n"
        , config.server_port
        , (char *)config.server_ip.str
        , config.server_mode
        , wav->str
        , (char *)config.command.str);

    if (config.server_mode)
        server_mode();
    else
        client_mode();
    return 0;
}

Conan sets include paths for imported libraries, so header files could be included directly. For a complete version of the example follow the GitHub repo.

Build the example

First of all, Canon must build imported libraries. Then created script conanbuild.sh should be sourced by bash shell. After that, CMake can generate build of our example. The following commands needs to build the project.

conan install . --output-folder=build --build=missing
cd build
source conanbuild.sh
cmake .. -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release
cmake --build .

Conclusion

Conan makes C developers happy but, not all libraries are available in main repository of Conan. So, C developers should make their self repository or use libraries with an understanding of more than one build tools.

DEV Community: Amin Khozaei

Reproducible Dev Environments

1. Nix

1.1. Core Concepts

1.2. Installing Nix

1.2.1. Linux

1.2.2. MacOS

1.2.3. Windows

1.3. Creating Isolated Environments with nix-shell

2. Nix Flakes

2.1. Anatomy of a Flake

2.2. Enabling Flakes

3. Devbox

3.1. Devbox Features

3.2. Quickstart

4. Automating with Direnv

4.1. Why Is This Useful?

4.2. Automatic Devbox Environments with Direnv

References

PlatformIO: A Better Way to Code for STM32 Microcontrollers

1. STM32 Microcontrollers

2. PlatformIO

3. ST-LINK

3.1. Prepare ST-LINK on Linux

4. Simple LED Blink and USART Project

4.1. Go to the PlatformIO Home screen.

4.2. Click on the New Project button on the right of the same screen.

4.3. PlatformIO Project Wizard

4.4. Directory Structure

4.5. Peripheral Configuration in STM32CubeMX

4.5.1. Clock Configuration

4.5.2. Pin Configuration

4.5.3. USART Configuration

4.5.4. Code Generating

4.5.5. Generated Code Structure

4.6. Coding

4.7. Build and Run

Resources

Automate Versioning with Git and CMake

1. What is Software Versioning?

1.1. SemVer

1.1.1. MAJOR version

1.1.2. MINOR version

1.1.3. PATCH version

1.2. Pre-release Versions

2. Automating SemVer with Git

2.1. Integrating SemVer with CMake

2.1.1. Template Files

2.2. Extract version information from a Git repository

2.3. using our custom CMake module

2.4. Printing Version Information

Resources

Conan: Your Embedded Cross-Compilation Champion

1. Integrate Conan as a Dependency Using CMake

1.1. Key Features of FetchContent

1.2. Resolve Canon Dependency in CMake

2. Defining Profiles for Cross-Compiling

2.1. Build Profile

2.2. Host Profile

3. Third-Party Libraries Using Conan

3.1. Searching for Libraries in Conan Center

3.2. Creating a conanfile.txt File

4. Integrating Conan with CMake

5. Use Libraries in Your Code

References

Design Patterns for C

1. What is a design pattern?

1.1. Object-oriented Paradigm

2. Creational Patterns

2.1. Factory design pattern

2.1.1. Key Concepts

2.1.2. Example Code

2.1.3. Known Uses

2.2. Singleton Pattern

2.2.1. Key Concepts

2.2.2. Example Code

2.2.3. Known Uses

3. Structural Patterns

3.1. Adapter Patterns

3.1.1. Key Concepts

1.3. Creating Isolated Environments with `nix-shell`

1.1. Key Features of `FetchContent`

3.2. Creating a `conanfile.txt` File