X-Git-Url: https://oss.titaniummirror.com/gitweb/?a=blobdiff_plain;f=doc%2Fhtml%2Ftep121.html;h=2b1ae7fb46ce4bb35c2c1b51f636bcf155b427b3;hb=e9bfab607e051bae6afb47b44892ce37541d1b44;hp=3653e4a391c3f7ddaccf591fb69ab2fe69c2e3a6;hpb=826bb539a6c489db5b216e7326bf693ec67d15e5;p=tinyos-2.x.git diff --git a/doc/html/tep121.html b/doc/html/tep121.html index 3653e4a3..2b1ae7fb 100644 --- a/doc/html/tep121.html +++ b/doc/html/tep121.html @@ -3,7 +3,7 @@ - + Towards TinyOS for 8051 +

Towards TinyOS for 8051

@@ -310,21 +306,20 @@ ul.auto-toc {
-

Note

This memo is informational. It will hopefully be a basis for discussions and suggestions for improvements. Distribution of this memo is unlimited. This memo is in full compliance with TEP 1.

-
-

Abstract

+
+

Abstract

This TEP covers our effort of porting TinyOS to the nRF24E1 platform. We ported the basic modules of TinyOS: Timer, UART, ADC and LEDS.

-
-

1. Project Outline

+
+

1. Project Outline

The original 8 bit 8051 chip is a member of the mcs51 family and was developed in 1980 by Intel. It is still to this date one of the most widely used microcontrollers. Porting TinyOS to the 8051 System on chip @@ -355,8 +350,8 @@ the 8051 features.

This work was done under the supervision of Martin Leopold at University of Copenhagen.

-
-

2. Project Approach

+
+

2. Project Approach

The approach to the porting project has been pragmatic. The focus has been on producing working code, so testing and debugging have been key elements of our work. The process has been to implement new @@ -381,12 +376,12 @@ input from the ADC pins.

-
-

3. Development Environment and Tool Chain

+
+

3. Development Environment and Tool Chain

The following subsections describe the different development tools, their selection and interconnection.

-
-

3.1 Selection of Development Tools/Compilers

+
+

3.1 Selection of Development Tools/Compilers

A large number of 8051 compilers exist primarily for the DOS and Windows platforms. We have focused on two popular and regularly updated compilers: KEIL and the Small Device C Compiler (SDCC).

@@ -417,8 +412,8 @@ the tool chain. We decided to substitute SDCC with the KEIL development kit. This gave us a working debug environment - with minimal change to the already produced code.

-
-

3.1.1 Our Recommendation

+
+

3.1.1 Our Recommendation

In our experience the SDCC compiler and associated tools are not yet mature enough to support our development. We recommend pursuing other alternatives such as KEIL or other compiler suites.

@@ -426,8 +421,8 @@ alternatives such as KEIL or other compiler suites.

the use of open source software and cross-platform development. We hope SDCC will prove an reliable alternative in the future.

-
-

3.2 Tool Chain Overview

+
+

3.2 Tool Chain Overview

The following figure and sections are an overview of the current tool chain. The tool chain is based on TinyOS 1.x, NesC 1.1.3, avr-gcc 3.4.3, PERL v. 5.8.6 and SDCC 2.5.4 or KEIL C51 version 7.20.

@@ -435,12 +430,12 @@ PERL v. 5.8.6 and SDCC 2.5.4 or KEIL C51 version 7.20.

              Mangle-
 TinyOS       script
------> app.c -----> app_mangled.c --------> app.hex ------> nRF24E1 
+-----> app.c -----> app_mangled.c --------> app.hex ------> nRF24E1
  NesC         PERL                SDCC/KEIL         nRFPROG
 
-
-

3.3 Description of the Tool Chain

+
+

3.3 Description of the Tool Chain

The compilation of the TinyOS test program outputs two files, a 'main.exe' file and an 'app.c' file. The 'app.c' file contains all the needed code to run the TinyOS application. However the C code produced @@ -456,8 +451,8 @@ as the rope, tying the output from NesC to the input of SDCC or KEIL.

produces a hex file that is transferred to the chip by the nRFPROG software.

-
-

3.4 Description of the Mangling Script

+
+

3.4 Description of the Mangling Script

The mangling script is written in PERL, a commonly used general purpose scripting language with powerful pattern matching capabilities and extensive handling of regular expressions. The mangle script handles all @@ -470,7 +465,7 @@ additional alterations.

or

-
"./sdccMangleAppC.pl -SDCC -file build/mcs51/app.c >
+
"./sdccMangleAppC.pl -SDCC -file build/mcs51/app.c >
build/mcs51/app_mangled.c"

The 'sdccMangleAppC.pl' script handles a number of needed alterations:

@@ -488,8 +483,8 @@ respectively

Each of these alterations will be explained in the sections below.

-
-

3.4.1 SFR and SBIT Declarations

+
+

3.4.1 SFR and SBIT Declarations

In order to make TinyOS accept the 8051 special function registers (SFR) and special bit variables (SBIT), we have included them into the TinyOS 8051 platform folder as a 8051.h file.

@@ -498,7 +493,7 @@ a specific bit within these SFR.

In order to make TinyOS accept the SFRs we have type defined them in the NesC code as:

-typedef int sfr; +typedef int sfr; sfr P0 __attribute((x80));

which is altered to

@@ -513,8 +508,8 @@ updated June 2003) for translating SFR and SBIT declarations from KEIL to SDCC, but it produces code with illegal syntax, so either do not use it, or alter it to produce code with the right syntax.

-
-

3.4.2 SDCC/KEIL Data Types

+
+

3.4.2 SDCC/KEIL Data Types

TinyOS and SDCC/KEIL do not support the same data types, so some alterations were needed to compile the code with SDCC and KEIL.

@@ -533,8 +528,8 @@ we are working with software that does not support this data type, on a very small hardware memory model, we decided to change the NesC 64 bit data types to 32 bit. This is done in the mangling script.

-
-

3.4.3 Reserved Keywords in SDCC

+
+

3.4.3 Reserved Keywords in SDCC

A number of keywords are reserved in SDCC. Half of them represent a directive to the compiler, defining which memory segment on the nRF24E1 the specific lines of code refer to. To ensure that the developer does @@ -599,22 +594,22 @@ Lower 128 bytes | direct and | KEIL it can be changed through selecting it in the options pane for the target.

-
-

3.4.4 Removal of inlining

+
+

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_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 +

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

-
-

3.4.5 Removal of Preprocessor Line Numbering

+
+

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 @@ -622,26 +617,26 @@ 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

+
+

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

+
+

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) +

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

+
+

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 @@ -653,26 +648,26 @@ 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  |  +---------+  +--------+ 
+| HPLClock |  |       HPLUART       |  | HPLADC  |      \/      HPL
++----------+  +---------------------+  +---------+
+  \/    /\        \/         \/  /\      \/   /\               -----
++----------+  +--------+   +--------+  +---------+  +--------+
+|  Timer2  |  | Timer1 | > | Serial |  | Sensors |  |  Port  |  HW
++----------+  +--------+   |  Port  |  +---------+  +--------+
                           +--------+
 

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

-