[Tinyos-8051wg] Issues with 8051

[Martin Leopold]

Hi All.
Let me open this forum by summarizing the issues that I have come
accross so far, relating to porting TinyOS to 8051 based platforms: in
general there are two groups of problems - the compiler differences
(Keil/sdcc vs. gcc) and the micro controller differences.

Compiler issues
===============
As a starting point I've chosen sdcc as a compiler, it is GPL and free
of charge, but most of the issues are the same for other non-gcc
compilers (Keil, CodeWarriors). The issues I've seen are:

* declaring a function as an interrupt handler is slightly different
  than gcc. Gcc uses __attribute sdcc uses a keyword "interrupt"

* data is a keyword in sdcc and cannot be used in identifiers, nescc
  generates structures with the name "data" (the CVS version of sdcc
  accepts this)

* $-in identifiers. nesC uses $ in identifiers. This can be solved by
  patching sdcc or by mangling $ to some other symbol. David Gay
  suggested extending nescc with C++ name-mangling.

* sdcc does not support inline or static inline. This is clearly a
  problem on memory constrained systems where stack-size is an issue.
  The solution range from implementing it in sdcc or nesC to providing
  a simple hack for example a Perl script[1].

The solution used by Cory Sharp/Mads Dydensbog for HCS08 platform with
the CodeWarriors compiler and for a PIC based platform[1] is to run a
simple mangle script on the generated app.c file. I have extended the
Cory/Mads script with the sdcc oddities, but it would be convenient
to have support for multiple compiler back-ends in nescc.

As a remark one could imagine the same script being used for HCS08 and
8051 as both are supported by sdcc.

8051 issues
===========
The 8051 operates with 3 separate address spaces (program, data,
scratchpad). Selecting which to be used in sdcc (and Keil I belive) is
done by specifying storage-qualifiers for each variable. In certain
cases we need some control of the select memory segment, especially for
the special function registers (SFR), but there might be performance
trade-offs to selecting one or the other, say external data memory
versus on-chip scratchpad.

Currently doing this in nescc is quite tedious and built in support
would be appropriate. My current solution is to annotate variables in
the .nc program in such a way that my mangle script can insert the
appropriate storage-class-qualifiers.

To go a bit further with the chip-specific issues, it seems unlikely
that anyone will ever run TinyOS on an old Intel produced 8051, but
rather on various compatible ICs or system-on-a-chip (SoC)
implementations. It is unclear to me at the moment what the different
vendors mean when they say 8051 compatible. There seems to be some
variation comparing to the Intel mcs51 users manual[2] especially
relating to the memory model. I'm confused to whether the chips contain
the extra indirect addressing space described by the 8052 model.

At the moment we are looking at two implementation: the 24E1 from
nVLSI[3] and the Oregano VHDL implementation[4]:

 * The 24E1 system from nVLSI is based on the DW80512[5] from SynopSys
   and they claim it looks like the DS80C320[6] from Maxim (ex.
   Dallas). Both seem to have the indirect address space.

 * The Oregano VHDL model that I'm trying to run on the Hogthrob
  platform. It is unclear to me which memory model it follows.

The compiler needs to be aware of the memory architecture to generate
appropriate code, but in general we need some control.


1. http://www.aws.cit.ie/Personnel/Papers/Paper261.pdf
2. http://www.intel.com/design/mcs51/manuals/272383.htm
3. http://www.nordicsemi.no/files/Product/data_sheet/nRF24E1rev1_2.pdf
4. http://www.oregano.at/index2.htm
5.
http://www.synopsys.com/cgi-bin/designware/ipdir.cgi?c=DW8051&c=DW_6811
6. http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2955

-- 
Regards Martin Leopold.
Dept. of Computer Science, University of Copenhagen