The embedded hierarchy – Part2

So how can we represent the embedded hierarchy in software? Before we can answer this question, we must make our goals clear:

• setting up and defining a new board should be as easy as possible, and
• code re-use should be optimal.

With these goals in mind, it is useful to divide the hardware hierarchy into three groups:

Group number 3 is not very suitable for building a software platform around. The reason is simple: this group is unrelated to key software components such as Operating System and toolchain. However, It does not mean that e.g. driver code for digital ICs has to be rewritten for every new board. This group simply does not determine the software platform structure/architecture.

The core (‘group’ number 2) such as ARM is the main processing unit and defines instruction set, cpu modes etc. Not only is the toolchain tightly coupled with it (how to build binaries without instruction set), the OS is too (e.g. how to perform atomic operations). Therefore, it should have an important place in a software platform. On the other hand, the core is not the highest level, re-usable hardware component: this honor goes to the MCU (see hierarchy).

The MCU (group number 1), more specifically MCU families, is just right:

• not too specific such as a board is (re-use is hard), and
• not too general such as a core is (re-use is fine but we can do better).

So for an embedded software platform, the hardware-dependent part can be organized around MCU families. This of course under the assumption that MCU plays a central role in the embedded hardware platform. This is very common but it does not necessarily have to be like that (e.g. Application Specific ICs).

This brings us to the concept of an embedded platform which is a combination of hardware and software platforms as illustrated in the diagram. Only key components and their relationships are shown. A well-known embedded platform is arduino.

A software platform is, of course, much more than what is shown in the diagram: it includes libraries and (middle-ware) extensions as well. In a broad sense, even a development environment (e.g. IDE) is a part of it. But this is not the focus of this article.

Time for our first example: FreeRTOS. In Part3 we’ll discuss Linux and our very own Siplab (= SImple PLatform ABstraction).

FreeRTOS-based software platforms

FreeRTOS has both hardware-dependent and independent parts. The hardware-independent part contains kernel components such as queues, tasks, co-routines and timers. In order to get these up-and-running, a hardware port has to be made. Here is the directory structure which tells a lot about the internal structure:

• Source/
  • include/: public headers
    • *.h e.g. task.h,
  • *.c: hardware independent e.g. task.c
  • portable/: hardware dependent part
    • toolchain/: compiler e.g. GCC
      • MCU-family/: e.g. ARM7_LPC2000
        • port.c, portISR.c, portmacro.h

So the hardware dependent part is organized around toolchain and MCU-family! This is not unexpected because:

• code tends to become more compiler-specific when close to the hardware, and
• MCU-family is key for generic hardware platforms (and software should reflect this -> code re-use is optimal!).

FreeRTOS-Plus offers various middle-ware components such as Internet-of-Things, CLI and networking stacks. Furthermore, FreeRTOS-IO (which is part of FreeRTOS-Plus) provides a  POSIX-like interface to peripheral drivers. A FreeRTOS-based embedded platform could then be a combination of FreeRTOS-plus, GCC and vim IDE.

But how should we define a board? We will postpone this discussion to Part3 in which we discuss Linux and Siplab.