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
- 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
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
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.