Follow our illustrated blog on Embedded Software Architecture

How to build a hybrid solar/wind energy harvester?

The embedded hierarchy – Part3

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Linux-based software platforms

Linux kernel

In this section the Linux kernel part of an embedded software platform is discussed.


While FreeRTOS (see Part2) has support for several compilers, the Linux kernel community has chosen GCC. Although less flexible, it simplifies things a lot and allows developers to take advantage of gcc specific features and extensions. Therefore, it is hard to build to kernel with another compiler technology (e.g. read this and this).

Architecture (in)dependent code

Although originally only written for x86, Linux has evolved to a general purpose OS which can run on lots of different architectures. There is only one way to achieve this i.e. by clearly separating architecture-dependent and architecture-independent code. ‘Architecture’ is typically (but not always) a cpu core type (e.g. arm, powerpc).

In the Linux kernel, the arch/ directory hosts architecture-dependent code:

  • arch/
    • alpha/
    • arm/
    • x86/

In these subdirectories, architecture-specific constructs can be found such as definition of atomic functions, boot code, barriers etc.


If we dig deeper, we find ‘machines’ or ‘platforms':

  • arch/
    • arm/
      • mach-at91/: machines based on Atmel’s at91sam processor family
      • mach-imx/: Freescale imx-based machines
    • powerpc/
      • platforms/
        • 83xx/
        • powermac/
        • ps3/

A machine (or platform) defines specific hardware. This could be a board or a generalization of it (e.g. board based on specific SoC, MCU or MPU). Terminology is not very clear here because a different layout is used for every arch/ subdirectory. In any case, developers try to re-use code between boards as much as possible.

Platform devices

A board always needs to describe a set of devices. These devices:

  • are integrated in the board’s MCU, or
  • are additional board peripherals (such as a temperature sensor).

These devices, called platform devices, can’t be automatically discovered and must be described somewhere. For long, this was done in the machine directory (and thus every board-spec change resulted in a kernel re-compile), but recently, this can be done in the board’s device tree (e.g. arch/arm/boot/dts). The device tree is a hierarchical description of the hardware, and only loosely coupled with the kernel. As a result, a new board definition does not necessarily result in a kernel re-compile.

Recently, device tree overlays have been developed in order to support BeagleBone capes or whatever kind of shield for small embedded devices. These overlays dynamically change the device tree, but it is still ongoing development.

More information about platform devices and device trees can be found here, here and here.

(Platform) Drivers

Platform devices only come to life when a compatible platform driver is found. Like any other Linux driver, they live in the drivers/ directory.

Linux User Space

Applications have access to the board’s functionality via standard Linux user space interfaces.

Devices (except for networking devices) are located in /dev e.g. /dev/ttyUSB0, /dev/rtc0.

Information on the system (cpu, memory, clocks… but also drivers and devices) can be found in sysfs (/sys), as well as in procfs (/proc).

Since application frameworks can be written in various ways, it is beyond the scope of this article.

Simple Platform Abstraction (SIPLAB)

To conclude this series, we describe the architecture of our very own SIPLAB, a thin abstraction layer between application and (RTOS and drivers). Siplab and the rationale behind it has already been discussed in this article. Here is an high-level overview:

simple platform abstractionThe directory layout of Siplab is explained next.

Directory structure

  • Siplab/VOS/
    • Lock
      • FreeRTOS
      • Linux
    • Thread
      • FreeRTOS
      • Linux

The Virtual OS directory (VOS/) implements basic OS features such as threads and locks. Supporting Linux enables developers to do host simulation.

  • Siplab/Platforms/
    • Pc/*c
    • Stm32f10x/*c
      • Board/*c
      • Drivers/
        • Adc/*c
        • Gpio/*c
        • PinConfig/*c
        • Pwm/*c
      • VOS/
        • FreeRTOS/

Siplab supports several hardware platforms. Currently, we support Stm32f10x and Linux host simulation (Pc/). Every platform might have several boards (Board/*c) and implements the common driver interfaces (Drivers/). The VOS/ directory has (mainly startup) code to get the VOS up-and-running on a specific HW platform.

The Board includes and common driver interfaces can be found in the one and only Include/ directory:


  • Siplab/Include/Siplab/
    • *h
    • Board/*h
    • Ext/*h

Of course, useful code is re-used and placed in common directories such as Libs/, Protocols/ etc.

Currently, Siplab only supports one toolchain which is GCC.

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)

Responsive software design without threads — Part 1

responsive event-based I/O design

We need a GUI thread. a common developer's reaction when the application only responds slowly to user clicks. The developer might be right: when some (gui) events require a lot of processing then having more than one thread, e.g. a GUI thread … [Continue reading]

Green4 serial test protocol and GUI

green4 power controller gui

Introduction For most embedded projects it is good practice to have basic tooling for testing I/Os. I/O primitives such as 'read gpio', 'set pwm duty cycle', 'read adc', not only allow engineers to verify hardware and software drivers, it might also … [Continue reading]

The red-black tree and hash table

red-black tree The even more advanced container we look at now is the red-black tree, which is a type of self-balancing binary search tree. Especially, interesting is the time complexity in big O notation: Action/Subject       Average          … [Continue reading]

3D printing of enclosures

printed in translucent white ABS

Having the correct and proper enclosures, is a mechanical (and also a marketing) problem many electronics projects suffer from. It is also related to anticipated sales numbers. For big numbers, a custom enclosure which is produced with an injection … [Continue reading]

Vector, list and tree

Choice of containers Information technology, even embedded devices, is about information gathering, processing or calculation, and control. Input and data needs to be juggled around and maybe sorted. In this article, we want to point out some … [Continue reading]

Priority inversion

I found the inspiration for this article while working on a consultancy job: Priority inversion. In computer science, priority inversion is a (potential) problematic scenario in scheduling in which a high priority task is indirectly preempted by a … [Continue reading]

Progress update

Time for another update. The Green4 project is progressing steadily. In the last few months, we have been busy preparing the Green4 prototypes. Test software has been developed which is already very usable, but it is still in a state of flux as we … [Continue reading]

Embedding a Basic interpreter

The green4 stm32 cortex m3 microprocessor we selected is - according to today's standards - a rather small microprocessor in Flash (128KB) and RAM (8KB). why an interpreter The Green4 device is running control software on top of FreeRTOS, with a … [Continue reading]

Green4 charge controller: wiring diagrams part 2

Wiring diagram: wind turbine to dump load In contrast to solar panels, a wind turbine can't be disconnected in case it generates too much power. We need to brake it by attaching a load to it. However, wind power can't always flow through the charge … [Continue reading]