[Tinyos-help] porting tinyos on new 32bit MCU

David Gay dgay42 at gmail.com
Thu Mar 3 08:15:25 PST 2005


[Long answer follows]

On Thu, 3 Mar 2005 14:50:22 +0530 (IST), santosh dwivedi
<santosh at iiita.ac.in> wrote:
> Hi Group,
> 
> I want to port TinyOS on 32 bit TMS470 MCU or TMS320F28XX
> 
> I know that it will involve writing platform specific code. But the first
> i need is a working make system for new platform.. although the ".. ..
> /platform/newplatform/" is empty yet ;-).. And for it I need a C compiler
> for TMS470/TMS320F28xx. TI provides windows based C compiler for them. But
> I am not sure about a gcc port. Is one available? 

Don't know about that...

> Can I use the windows based compiler? 

The answer is yes, but some significant work required, see below (I'll
assume this compiler can be invoked from the command line, though...).

> Also what sort of changes I need to do in make system for
> supporting my new platform. I use cygwin this time.

Somewhat long answer on compiler/make system issues for new platforms
follows (the "significant work" is described at the end...):

The TinyOS compilation environment has three parts:
- a "make system" (something of a misnomer, it's built using make but
only bears a passing ressemblance to standard uses of Makefiles...)
- a nesC compiler driver (ncc)
- the nesC-to-C compiler (usually found in /usr/local/lib/ncc/nesc1)

Roles:
- the "make system" is sort-of like an IDE (minus the text editor): it
provides simple ways to compile, install and otherwise manage TinyOS
programs for different platforms, using a set of standard options. To
do this, it invokes 'ncc' (to compile) and various mote-programming
tools ('uisp', 'msp430-bsl', etc).

- "ncc" is the driver for the nesC compiler. It is (purposefully)
designed to work as an extension to "gcc" (the driver for all the GNU
compilers). In particular, ncc accepts all gcc options and will also
happily compile C files, assembly code, etc. It does this by simply
invoking gcc with a few extra options to make gcc recognise .nc files
(*).

- "nesc1" is the actual nesC compiler. It reads in nesC components and
C source files, and outputs a C file (usually found in
build/<platform>/app.c, though this is just the result of the
-fnesc-cfile=build/<platform>/app.c option added by the "make
system").

How to add a new platform if your target supports gcc:

- Extend the "make system" to have compilation, installation options
for your new platform. See tinyos-1.x/tools/make for details. You can
probably copy and modify an existing platform without too much
trouble...

- Make "ncc" recognise your platform: "ncc" requires each platform
directory to contain a .platform file (written in perl) which
specifies compilation options for that platform. This is generally
quite simple -- check the mica, telosb, etc .platform files. You can
do anything you want in this file actually, it's just run half-way
through the "ncc" script. I'd recommend reading /usr/local/bin/ncc if
you want to do anything fancy.
   For "ncc" to accept -target=<newplatform>, you must either: place
your <newplatform> directory in tos/platform, or specify -I<path to
newplatform> as an option to "ncc".

- Get "nesc1" to understand your new platform. You should be able to
use the "env" target documented in tinyos-1.x/doc/nesc/envtarget.html.
You will also need to use the 'hwevent' or 'atomic_hwevent' attributes
to mark your interrupt handlers. 'hwevent' should be used on interrupt
handlers which run with interrupts enabled, 'atomic_hwevent' on
interrupt handles which run with interrupts disabled.

How to add a new platform if your target uses a non-gcc compiler:
- "make system": this should be fairly similar to what you would do
for a gcc-based target, but it's probably going to invoke some
alternative to "ncc" with somewhat different options (see below).
You'll have to build more stuff yourself. [A little work required]

- "ncc": ncc's goal is to work just like "gcc", so that you can pass
all relevant options on for the link step, specify the gcc
optimisation levels, debugging options, etc, which you want to apply
while compiling the C output from "nesc1". If you're using a
non-gcc-based compiler, these options are clearly going to be
different, so you'll want a different compiler driver. There's no
particular reason that this driver has to look much like "ncc" - it's
all up to you... [Some work required]

- "nesc1": this is where you may have more fun. "nesc1" is a full
compiler frontend, based on gcc, which understands the various gcc
extensions (but, for those who care, it doesn't have most of the C99
features). [More work required]
  If your target compiler has its own extensions to C, and these are
used in include files you care about (i.e., the include files for some
C library which you want to use in your TinyOS code) you will have to
extend "nesc1" to understand these extensions. This means: parsing
them correctly, issuing appropriate error messages when they are
misused (**), and outputing them when "nesc1" produces the C code for
your nesC application. If the extension has effects on some aspects of
C (e.g., types, declarations of variables, etc, etc), you may have to
make other changes to nesc1. Some experience writing compilers is
probably helpful for this process...
  If your target compiler is basically strict ANSI C, then things
should not be too complicated. nesc1 should happily parse and output
your header files. You are likely to run into two issues:
    o nesc1 recognises gcc's options for controlling warnings, etc
(e.g., -Wall). These are presumably different from your target
compiler. You have to decide what options you want to present to users
(via the "make system" and your "ncc" replacement), and how these will
map to nesc1's existing options. Or you might just require users to
specify both gcc-style options and your-target-compiler-style
options...
    o nesc1 currently ignores #pragma's. It needs to preserve these,
and output them in the right place (the "right place" is the tricky
part - nesc1 outputs its C code in an order unrelated to how it was
found in the input files...). If you need to fix this, the
save_directive function and nesc-generate.c, unparse.c files are good
places to start...


David Gay
*: note that "gcc" is NOT the C compiler. It's just a program that
invokes compilers, assemblers, linkers based on its command line
options.
**: you can cheat here (ignore some errors) to some extent, relying on
the target compiler to produce necessary errors and warnings based on
the C code output from nesc1.


More information about the Tinyos-help mailing list