A State-Based Programming Model for Wireless Sensor Networks

6.2. OSM Language Mapping 113
Esterel-Code Generation from OSM
The exact details of mapping OSM to Esterel are only of secondary importance.
Therefore, and due to space constraints, we will present the mapping by example
only. Appendix A.1 shows the OSM program PROG_PAR depicted in
Fig. 6.2, its mapping to Esterel, and the C code generated by the Esterel compiler.
The program is a parallel composition of the OSM state machines presented
in Programs 6.1 and 6.2. It has 10 states and contains most features of
OSM. Table 6.1 compares the sizes (in terms of lines of code) of the original OSM
implementation and the generated C and Esterel mapping code.
Compilation
Unit
# Lines Comment
test.osm 49 original OSM implementation
test.h 80 variable mapping (C)
test.strl 307 control structure mapping (Esterel)
test.c 616 control structure mapping (C)
Table 6.1: Number of lines of code for an OSM program and its mappings in C
and Esterel.
In this section we demonstrate that the event-driven code generated by OSM
does not introduce unacceptable overhead. To this end, we analyze the variable
memory and code size of OSM programs. As described previously, the OSM
code is first translated into Esterel code, from which C code is generated. Therefore
we analyze the object code generated from C code by a C compiler. Since
our target platform is the BTnode, we compile for the Atmel AVR 128 microcontroller,
the BTnode’s CPU. The compiler used is GCC for AVR (avr-gcc), version
3.4.3.
We start by analyzing the Programs 6.1 and 6.2 from the last section. Using
these programs as base modules, we the build more complex programs by sequential
and parallel composition.
C-Code Generation from Esterel
The Esterel compiler has several code generation modes and target languages.
We use ANSI C in the sorted equations mode. The original C output of the
Esterel compiler for program P ROG_P AR depicted in Fig. 6.2 is shown in Appendix
A.4.1. The state transition function basically compiles into a long list of
boolean equations that operate on a large amount of boolean variables. These
variables store the machine’s internal program state as well as temporary state
during the function’s execution in two large array of chars. The representation
of boolean values as chars is inherently memory inefficient. Therefore we modify
the Esterel-generated C code to use bitfields instead, as exemplified below.
Bitfields are a C mechanism for addressing individual bits of a struct. The necessary
modifications are made by a Perl script but currently require some human
intervention, though the task could be fully automated. Note that these modifications
are required only when compiling for the BTnode. Development and
initial program testing is typically performed in the BTnode emulation environment
on a PC, where size is not an issue.