tep121.txt

tinyos-2.x.rar

allocated in the directly addressable portion of the internal RAM. This
is the default option for the small memory model. Variables declared
with storage class xdata/far will be placed in external RAM, which is
default for the large memory model.

Variables declared with keyword storage class idata will be allocated in
the indirectly addressable portion of the internal RAM. The first 128
byte of idata physically access the same RAM as the data memory. The
original 8051 had 128 byte idata, but nowadays most devices have 256
byte idata memory. Paged xdata access (pdata) is just as
straightforward.

The different memory segments that the keywords apply to, can be seen in
the figure below.

nRF24E1 Internal Data Memory Structure Overview::

                        IRAM                  SFR
                 +---------------------+---------------------+
             FFh |                     |                     | FFh
                 |   Accessible by     |   Accessible by     |
 Upper 128 bytes |   indirect          |   direct            |
                 |   addressing only   |   addressing only   |
             80h |                     |                     | 80h
                 +---------------------+---------------------+
             7Fh |                     |
                 | Addressable by      |
 Lower 128 bytes | direct and          |
                 | indirect addressing |
             00h |                     |
                 +---------------------+

The prefered memory model can be defined in SDCC through CLI option
--model-small or --model-large - the small memory model is default. In
KEIL it can be changed through selecting it in the options pane for the
target. 


3.4.4 Removal of inlining
--------------------------------------------------------------------

NesC assumes that GCC is being used for the final compilation. GCC
supports inline functions and can be made to optimize code quite
aggressively, so the code generated by NesC does not need to be very
efficient. Unfortunately SDCC does not support code inlining, so the
inline statements have to be removed, when compiling for SDCC.
 
Lines with the following format are affected:

static inline void TOSH_sleep(void ); 
static __inline void TOSH_SET_RED_LED_PIN(void);
__inline void__nesc_enable_interrupt(void);

Lines with the noinline attribute is substituted with the 
#pragma NO_INLINE.

3.4.5 Removal of Preprocessor Line Numbering
--------------------------------------------------------------------

Also NesC produce preprocessor line number meta data, to allow the
compiler to report error messages referring to the original code. We do
not really need them for anything, so we filter them out to minimize the
code size. It also eases the code reading significantly. If needed for
debug purposes the regular expression in the mangle script which remove
them can be commented out.

3.4.6 Change $ in Identifiers
--------------------------------------------------------------------

The SDCC compiler is very strict when it comes to valid symbols in
identifiers. NesC produce GCC-code which inserts $ as a separator
character in identifiers. We mangle the $ to two underscores in order to
enable SDCC/KEIL to compile.

3.4.7 Interrupt Vectors
--------------------------------------------------------------------

The syntax for declaration of interrupt vectors are different in GCC and
SDCC/KEIL. So we mangle the interrupt declaration:

From: void __attribute((interrupt)) __vector_5(void) 
To:   void __vector_5(void) interrupt 5

Additionally KEIL does not understand that the interrupt vector is
defined previous to its use. So we remove the forward declaration of the
vectors in the mangle script, when compiling for KEIL.


4. TinyOS Modifications
====================================================================

TinyOS is based on modules with different levels of hardware
abstraction. When porting TinyOS to a new platform, you change the
underlying hardware dependencies in TinyOS, and you have to rebuild the
modules bottom up. Hence, it has been necessary to modify a number of
modules in TinyOS. The figure below shows the topological hierarchy of
the TinyOS modules we have focused on. By far, most of the work has been
done in the Hardware Presentation Layer (HPL), but certain changes also
affected the higher abstractions, such as changes in interfaces and
interrupt handling.

Modified TinyOS modules overview::

 +------------------------------------------------------------+ 
 |                     TinyOS Application                     |  App
 +------------------------------------------------------------+ 
   \/    /\            \/    /\           \/   /\      \/  /\   -----
 +----------+        +----------+       +---------+  +--------+ 
 |  Timer   |        |   UART   |       |   ADC   |  |  LEDs  |  HAL
 +----------+        +----------+       +---------+  +--------+
   \/    /\            \/    /\           \/   /\               -----
 +----------+  +---------------------+  +---------+ 
 | HPLClock |  |       HPLUART       |  | HPLADC  |      \/      HPL 
 +----------+  +---------------------+  +---------+
   \/    /\        \/         \/  /\      \/   /\               ----- 
 +----------+  +--------+   +--------+  +---------+  +--------+ 
 |  Timer2  |  | Timer1 | > | Serial |  | Sensors |  |  Port  |  HW 
 +----------+  +--------+   |  Port  |  +---------+  +--------+ 
                           +--------+

The following sections describe the changes to the four groups of modules.

4.1 HPLClock and related modules
--------------------------------------------------------------------

The 8051 chip has three independent timer/counter circuits: Timer0,
Timer1 and Timer2, which can run in various modes. Each timer/counter
consists of a 16-bit register that is accessible to software as three
SFRs (TL0/TH0, TL1/TH1 and TL2/TH2). Timer0 and Timer1 can be used as 13
or 16 bit timer/counter or as 8 bit counters with auto-reload. Timer2 is
only capable of running as a 16 bit timer/counter, but can remain as
such even in auto-reload mode. Reload is desirable for loading the clock
with a start value.

We have chosen to use Timer2 for the clock module, since it gives our
design a maximum clock interval of 49.15 ms at a 16 MHz system clock.
Using a different timer circuit would limit the interval to 0.192 ms,
which would result in a great deal of interrupts and consume processing
power for administrational overhead.

4.1.1 Timer
--------------------------------------------------------------------

The Timer module (HAL) uses the HPLClock module to handle the hardware
timing.  These two modules communicate through the clock interface.
However, the standard TinyOS clock interface is designed for an MCU with
a more flexible prescaler, then the 8051 chip is equipped with. The 8051
is limited to a prescaler with a factor of 1/4 or 1/12 of the CPU clock
frequency, whereas the TinyOS clock interface currently uses an 8 bit
prescaler and an 8 bit timer.  Because of the 8051s limited prescaler
options, and the possibility to use a 16 bit timer/counter to compensate
for the reduced prescaler options, we decided to widen the clock
interface from 8 to 16 bit. We are using the factor 1/4 for the
prescaler.

The interface change has affected the following methods: 
result_t setRate(uint16_t interval, char scale) 
void     setInterval(uint16_t value) 
void     setNextInterval(uint16_t value) 
uint16_t getInterval()
result_t setIntervalAndScale(uint16_t interval, uint8_t scale)
uint16_t readCounter() 
void     setCounter(uint16_t n)  

See: 
  Clock.h 
  Clock.nc 
  HPLClock.nc 
  TimerM.nc 
  TimerC.nc 
  8051.h

4.2 HPLUART
--------------------------------------------------------------------

The UART is depending on a timer to generate a baud rate for the serial
port. The architecture only allows two of the three timers (Timer1 or
Timer2), to act as such. Since Timer2 is already used by the clock
module, this leaves only Timer1 available for the UART module. 

When using Timer1 as the baud rate generator, 5 different baud rates can
be obtained: 1.20 KiB/s, 2.4 KiB/s, 4.8 KiB/s, 9.6 KiB/s or 19.2 KiB/s.
We chose to use a baud rate of 19.2 KiB/s with 8 data bits, no parity
and one stop bit, since this speed is commonly used and the fastest
speed possible using this timer.

We have also expanded the HPLUART interface to include a put2 method.
This method is able to send more than one byte, by taking two pointers
as arguments. These pointers refer to the first and last bytes to be
sent. The HPLUART interrupt handler was also modified to take the
multiple byte data into account.

See: 
  8051.h 
  HPLUART.nc 
  HPLUARTC.nc 
  HPLUARTM.nc

4.3 HPLADC
--------------------------------------------------------------------

The TinyOS standard ADC interface was developed for the AVR which
includes hardware functionality for repetitive sampling at a given
interval.  Implementing this functionality on the 8051, which does not
support this in hardware, would require use of the last timer. We chose
not to implement repetitive sampling, therefore the setSampleRate method
currently has no use. 

See: 
  8051.h 
  ADCM.nc 
  HPLADCC.nc 
  HPLADCM.nc

4.4 LEDS
--------------------------------------------------------------------

TinyOS features three standard LEDs (Red, Green and Yellow), but the
nRF24E1 evaluation board is not equipped with programmable LEDs so we
used the general purpose ports (GPIO).

The standard 8051 platform features four 8 bit GPIO, however the nRF24E1
evaluation board is only equipped with two ports: Port0 and Port1, where
Port0 has eight bits and Port1 has only three bits. 

Intuitively the best solution would have been to place the standard
three TinyOS LED bits on Port1, but unfortunately we were unable to
control the most significant bit on Port1, since it is hard-wired as
input and controlled by external SPI_CTRL. The Yellow LED was moved to
Port0.

To visualize the status of the GPIO, including the three standard LEDs,
we built a LED expansion board.

The three LEDs are currently wired to: 
  Red -> P1.0 
  Green -> P1.1
  Yellow -> P0.7.

See: 
  8051.h 
  hardware.h 
  mcs51hardware.h 
  LedsC.nc

4.5 Interrupts
--------------------------------------------------------------------

In TinyOS interrupts are not implemented as a single module, they are
mainly facilitated in atomic blocks and in the init, start and stop
methods of the various HPL modules. The init, start and stop methods
only handle interrupts that are specific to the module, i.e. timer
interrupt for the HPLClock module and serial interrupt for the HPLUART
module. While the atomic block handle the enabling of global interrupts.
This is used to avoid preempting code execution in critical blocks.


5. Conclusion
====================================================================

The project have reached a plateau of development in porting TinyOS to
the 8051 platform, on which future development can be based. The basic
modules (Timer, UART, ADC and LEDS) have been implemented making 8051
accessible for the TinyOS community. However a essential module for the
field of sensor networks, the radio module, is still missing.

The result of our work will be uploaded to the TinyOS 8051 Working Group
website.


6. Future Work
====================================================================

The work presented in this TEP is short of being a complete porting of
TinyOS to the 8051 platform. Two obvious future tasks are implementing a
Radio module involving the SPI interface and Power Management for duty
cycling. The radio module is currently under development, in which the
main hurdle is the three wire SPI interface.

This work is done for TinyOS 1.x, but looking forward, the 8051 port
should target TinyOS 2.0. This might be a challenge with the timer
interface being so different from TinyOS 1.x.


7. Authors
====================================================================

| Anders Egeskov Petersen 
| University of Copenhagen, Dept. of Computer Science 
| Universitetsparken 1 
| DK-2100 K鴅enhavn