Welcome to Ars-Informatica  


If you want to build a ship don't herd people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. (Antoine-Marie-Roger de Saint-Exupéry)

MetroC: embedded system C++ framework

This framework embraces platform based design methodology and builds on its pillars the instruments required for the development of an embedded system.

As already stated the building of an embedded system involves a multi stage work, starting from high level specifications down to the hardware fabric realization and OS development.

This process may be prune to many errors and not always there exists a well defined manner to face the level transition process that from the high level of abstraction brings painlessly down to the final prototype.

There exist also different languages that may be more adequate according to the level of abstraction: natural language for the design specifications, C/C++ for the OS development and Verilog/VHDL for the hardware implementation.

In order to leverage this issue a framework has been defined. The implementation is in C/C++ because it is the most widespread language in the embedded systems world. It is defined in such a way that it can be used `as is' to develop an entire embedded system on a standard PC.

It has the following features that make it unique:

  • it can cooperate with other languages/tools/domains by defining an advanced `black box' mechanism;
  • it is thought to be part of the final embedded system implementation.

For a quick overview of such mechanism a toy example of an hardware adder is represented in figure

Suppose the aim is to develop a new embedded system starting from scratch (the cpu included). After having defined what the system is supposed to do (the algorithm) the user now face the first step: test the algorithm. This test can be performed on the local system (i.e. pc with x86 cpu and Windows OS or Linux OS). Then it may target another system by cross-compiling the application for the target. This step is equivalent to substitute every single instruction to the call to a generic execute that eventually feeds the target system execute pipeline. This mechanism is shown in the right part where the operation of adding two integer has been transformed into an assembler instruction that runs on the embedded processor. The `execute' call just transfer execution to another system that may be anything:

  • a driver to control the i/o functions in an embedded ECU
  • an instruction set simulator to run different pieces of code on some target processors/microcontrollers;
  • an embedded systems simulator endowed with an advanced debugger to develop a real time OS.

Therefore the transformation shown above that reproduces the steps performed by a cross compiler is just one example. The `execute' hides the complexity and can represent different systems according to the level of abstraction the designer decides to work with. The first `execute' may be the call to the pc-x86 development system simulator. This allows the designer to test the system at early stages. A second step would require part of the design to be cross-compiled for the target system (a subset of the final system such as the cpu, the microcontroller, the so-called human interface, etc). This is equivalent of walking through the design exploration space shown on the left side of figure

by splitting/refining the original `execute' with a number of `executes' related to the number of subsystems.