BAKKALAUREATSARBEIT

TinyOS, an Embedded OperatingSystem

ausgefuhrt zum Zwecke der Erlangung des akademischen Gradeseines Bakkalaureus der Technischen Informatik

unter der Leitung von

Dipl.-Ing. Alexander Kossler

Institut fur Technische Informatik 182-2

durchgefuhrt von

Harald GlanzerMarkus Hartmann

Matr.Nr. 0727156Matr.Nr. 9808811

Wien, im September 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . .

TinyOS, an Embedded OperatingSystem

Subject of this work is to give an introduction to the TinyOS EmbeddedOperating System. It explains the internal structure of the OS and pointsout its characteristics by comparing it to another embedded OperatingSystem called MicroC/OS-II. By presenting several modules which havebeen written in the course of this project thesis the usage and practicalapplicability of TinyOS are shown. A setupguide for the used toolchainis provided in order to enable a quick and simple start into applicationdevelopement.

i

Contents

1 Introduction 11.1 Motivation and Objectives . . . . . . . . . . . . . . . . . . . . . 11.2 Structure of the Thesis . . . . . . . . . . . . . . . . . . . . . . . 2

2 TinyOS 32.1 What is TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 History of TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Supported Platforms . . . . . . . . . . . . . . . . . . . . . . . . 42.4 TinyOS Hardware Abstraction . . . . . . . . . . . . . . . . . . . 52.5 TinyOS Internals . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5.1 Basic Scheduler . . . . . . . . . . . . . . . . . . . . . . . 62.5.2 Microcontroller Power Management . . . . . . . . . . . . 62.5.3 Boot Sequence . . . . . . . . . . . . . . . . . . . . . . . 72.5.4 Ressource Arbitration . . . . . . . . . . . . . . . . . . . 8

3 nesC 113.1 Fundamental Programming Hints . . . . . . . . . . . . . . . . . 113.2 Namespace, Components, and Interfaces . . . . . . . . . . . . . 123.3 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.4 Async Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5 Split-Phase Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 163.6 Generic Components . . . . . . . . . . . . . . . . . . . . . . . . 173.7 Parameterized Interfaces and Configurations . . . . . . . . . . . 183.8 Wiring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.8.1 Modules vs. Configurations . . . . . . . . . . . . . . . . 193.8.2 Wiring-Operators . . . . . . . . . . . . . . . . . . . . . . 19

4 MicroC/OS-II 224.1 Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Differences TinyOS - MicroC/OS-II . . . . . . . . . . . . . . . . 23

4.2.1 Real-Time . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.2 Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.3 Mutual Exclusion . . . . . . . . . . . . . . . . . . . . . . 244.2.4 Intertask Communication . . . . . . . . . . . . . . . . . 254.2.5 Task Synchronisation . . . . . . . . . . . . . . . . . . . . 254.2.6 Memory Footprint . . . . . . . . . . . . . . . . . . . . . 25

ii

5 bigAVR6 265.1 The Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.1.1 Onboard - Features . . . . . . . . . . . . . . . . . . . . . 265.1.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 Supported Modules . . . . . . . . . . . . . . . . . . . . . . . . . 275.2.1 Character LCD 2x16 . . . . . . . . . . . . . . . . . . . . 275.2.2 GLCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2.3 Touch Screen . . . . . . . . . . . . . . . . . . . . . . . . 315.2.4 MMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.2.5 MP3 extension board . . . . . . . . . . . . . . . . . . . . 345.2.6 Ethernet board . . . . . . . . . . . . . . . . . . . . . . . 365.2.7 UART . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.8 RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.9 Printf Library . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 Supported Microcontrollers . . . . . . . . . . . . . . . . . . . . . 445.3.1 ATmega128 . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.2 ATmega1280 . . . . . . . . . . . . . . . . . . . . . . . . 45

6 Resources used 46

Bibliography 47

A Setup Guide 48A.0.3 Visualize Components . . . . . . . . . . . . . . . . . . . 49

B Pin Configuration of bigAVR6 50

iii

1 Introduction

This work is about the porting of TinyOS for the bigAVR6 platform for usein the Microcontroller Lab Course at the Vienna University of Technology.TinyOS is an open-source operating system, designed for use with wirelessembedded sensor networks. There are 2 major stable branches, v.1.x and v2.x,which are not compatible to each other. TinyOS 2.x introduced some majorimprovements, for example the task scheduler was completely redesigned. Init’s new version, the whole project is now distributed under the new BSD licensetoo.

Because of TinyOS’s component-based architecture, a high-level programmerdoes not have to rewrite all the used components from scratch, as long as thenecessary modules are already exisiting. So, implementing new applications orchanging exisiting ones is an easy and fast task. There are already existingimplementations for a range of popular hardware motes, as for example themica, iris and teleosa motes.

For developing applications in TinyOS, nesC is used. nesC stands for Net-work Embedded Systems C, which is very similar to C/C++. Components innesC are related to objects in C++.

Embedded systems are designed for one or a few specific tasks, perhaps incombination with realtime constraints. TinyOS was originally developed forwireless, battery powered sensor networks, so one of the main requirements islow power consumption to achieve high operation times – flexibility is not thatimportant.

This work captures topics from porting TinyOS to the bigAVR6 platformas well as extending it by adding software-modules for high-level use of theplatform modules. It is also explained how to get a build environment runningfrom scratch for writing applications or extending the modules for an exisitingplatform.

1.1 Motivation and Objectives

One goal of this work is to provide an easy-to-use manual for using TinyOSto the reader, so that a build environement can be set up from scratch step-by-step with very little previous knowledge needed. By comparing TinyOS to

1

1 Introduction 1.2 Structure of the Thesis

MicroC/OS-II, another embedded operating system, the specific characteris-tics of TinyOS will get much clearer. Finally, by guiding through the softwaremodules written for the bigAVR6-board, the reader will get familiar with howto practically extend the TinyOS framework by using as much of the preex-isting components and how to properly integrate his own code into TinyOSapplications.

1.2 Structure of the Thesis

The thesis is structured as follows:

Chapter 2 gives an overview over TinyOS and explains its internals.

Chapter 3 gives an introduction to nesC.

Chapter 5 introduces the developement platform bigAVR6, for which TinyOSwas ported to by the authors, and explains the supported devices for thisplatform.

Chapter 4 introduces another embedded operation system, namedMicroC/OS-II, and compares it’s main characteristics to TinyOS.

Appendix A provides a Setup guide for the TinyOS toolchain.

Appendix B shows an overview for the bigAVR6 pin configuration.

2

2 TinyOS

2.1 What is TinyOS

TinyOS is a free and open operating system for hardware motes, written innesC. A hardware mote is a microcontroller based node in a wireless sensornetwork, capable of reading sensory information, processing and exchangingits data with other nodes. Communication typically happens via a wirelessnetwork, to reduce the cost for deployment and maintenance. Additionally, inmany environments wires are not feasible.

Development of TinyOS started as a collaboration of Berkeley Universitywith Intel Research and Crossbow Technology, a california based company.The following requirements were defined for TinyOS:

• Require very few resources

• Allow fine-grained concurrency

• Adapt to hardware evolution

• Support a wide range of applications

• Robust design

• Support a diverse set of platforms

One of TinyOS’s most important features is that TinyOS applications arebuilt out of components, which are connected (or wired) to each other byinterfaces. Components can easily be developed, extended and reused. Anotheradvantage is that a component can be built in software or hardware, increasingflexibility.

2.2 History of TinyOS

Developement of TinyOS started in 1999 at Berkeley university. The firstsupported platform was a mote called ’WeC’, shown in Figure 2.1. For com-munication, this platform is equipped with a radio device, SPI- and UARTinterfaces. An Atmel AVR AT90LS8535 microprocessor, clocked with 4MHz,is used as MCU.

3

2 TinyOS 2.3 Supported Platforms

Figure 2.1: WeC Mote

Over the next years, the ’rene’ and ’mica’ platforms were developed. In theyear 2002, work on the nesC programming language began. Until that, TinyOSconsisted of a mixture of C files and Perl scripts. In the same year, TinyOS1.0, the first TinyOS implemented in nesC, was released.

Improvement of TinyOS 1.x went on until February 2006, when TinyOS 2.0beta1 was released. Version 2.1 was finished in April 2007. Among numerousbugfixes, a cc2420 wireless radio stack implementation was added in this release.TinyOS 2.2 was released some months later, which included an cc2420 stackreimplementation and bugfixes. After that, in August 2008, support for the’iris’ and ’shimmer’ platforms was added by distribution of version 2.1.

At the time of this writing, the latest TinyOS version is 2.1.1, which wasreleased in April 2010. Most important add-ons were support for the ’mulle’,’epic’ and ’shimmer2’ - platforms.

2.3 Supported Platforms

In the current version, a range of hardware motes are supported out-of-the-box.A brief description of this platforms and its most important communication de-vices are given in the following list. Obviously, most of this platforms provideinterfaces for UART, I2C, SPI, or other peripherals, depending on the micro-controller and extension boards used, too. These features are not listed here.

• btnode3: Atmega128L cpu and radio/bluetooth communication devices

• epic: MSP430 cpu and CC2420 radio chip

• eyesIFX: MSP430F149/F1611 and TDA5250 wireless transceiver

• intelmote2: PXA271 XScale cpu and CC2420 radio chip

• iris: Atmega1281 and AT86RF230 radio chip

• mica: Atmega103 and TR1000 radio chip

4

2 TinyOS 2.4 TinyOS Hardware Abstraction

• mica2: Atmega128L and Chipcon 868/916 radio chip

• mica2dot: Atmega128 and cc1000 transceiver

• micaz: Atmega128 and CC2420 radio chip

• mulle: Renesas M16C and AT86RF230 transceiver

• sam3s ek: SAM3S4C chip and cc2520 transceiver

• sam3u ek: SAM3S4C chip and cc2420 transceiver

• shimmer / shimmer2 / shimmer2r : MSP430 cpu and CC2420 transceiver

• span: MSP430 cpu and CC2420 transceiver

• telosa / telosb: MSP430 cpu and CC2420 transceiver

• tinynode: MSP430 cpu and Semtech SX1211 transceiver

• ucmini: Atmega128RFA1 cpu(low power transceiver cpu integrated)

• z1: MSP430 cpu and CC2420 transceiver

2.4 TinyOS Hardware Abstraction

Many of the supported hardware platforms use the same cpu and/or communi-cation hardware. Hardware abstraction is used to avoid rewriting of code, mak-ing it easier to port applications from one platform to another. Additionally,application development itself gets easier, too. On the other hand, abstractionmeans generalisation, which is problematic because hardware motes only havevery limited resources and strict energy-efficiency requirements. TinyOS uses a3-level Hardware Abstraction Architecture to provide a flexible and performantframework to build applications on, as shown in Figure 2.2.

• Hardware Presentation Layer (HPL): Low Level components, directlyaccessing the hardware.

• Hardware Adaption Layer (HAL): Platform specific abstractions hidinga bit of the complexity from hardware resources, allowed to perform ar-bitration and resource control.

• Hardware Interface Layer (HIL): Hardware independent application in-terface

The 3-level Hardware Abstraction tries to provide a balance between effi-ciency and portability. In contrast to other embedded operating Systems thatuse only 2 layer abstraction, the third TinyOS layer provides more flexibility.For maximum performance, a Platform specific application can directly hookinto the HAL, circumventing the HIL. h

5

2 TinyOS 2.5 TinyOS Internals

Figure 2.2: Hardware Abstraction Architecture

2.5 TinyOS Internals

2.5.1 Basic Scheduler

By default, TinyOS 2.x uses a non-preemptive FIFO scheduler with a max-imum of 255 parameterless tasks waiting for execution. A task can only bescheduled once at a time, if periodic execution is needed the task has to re-postitself. The scheduler itself consists of an interminable for-loop, that pops (=executes) one task after the other, in sequence as the tasks got pushed. Ifno tasks are waiting for execution, the scheduler enters a powersaving-modeimmediately.

Because the scheduler of TinyOS is implemented as a component it is possibleto replace this default FIFO-scheduler with a selfwritten one. See [LS] fordetails how to implement a selfwritten scheduler.

2.5.2 Microcontroller Power Management

To reduce power consumption, a microcontroller should always run in the lowestpower state possible. For example, if you want to run an embedded system thatis powered by two AA batteries with a capacitiy of 2.7Ah, for one year, youreach an average of about 1mW of power consumption. Clearly, this can onlybe achieved by saving energy whenever possible.

6

2 TinyOS 2.5 TinyOS Internals

As mentioned before, TinyOS enters a low power mode if the task queue isempty. Normally, microcontrollers support a range of low power modes, forexample the ATmega128 supports up to 6 different power saving modes. Todecide what mode fits best, TinyOS examines the control- and statusregistersto find the active components, and decides subsequently which power mode touse.

For example, on an ATmega128-based asynchronous operated platform, thecpu-specific powersaving-mode IDLE has to be choosen if one or more timer,SPI, UART or I2C are in use. If the ADC-submodule is working, another mode,ADC Noise Reduction, is entered. If none of this modules are active and thetask queue is empty, the cpu is set to POWER DOWN, from which it only canresume by some external interrupts/resets or a SPI address match interrupt.

Because entering powersaving modes always comes with wakeup latency,problems can arise if some higher-level hardware modules have timing con-strains and the wakeup latency is too big. To solve this, the powersavingmode found by examing the control- and statusregisters can be overriddenby a higher-level module. For example, when going to a sleepmode just be-fore an alarm of a timer would occur, the wakeup latency could probablycause a miss of this alarm. Therefore, a component can provide an inter-face named McuPowerOverride featuring a command lowestState that, wiredagainst McuSleepC, will be called when a powersave mode is requested, andcan override the valid powersaving mode. The enabled powersaving mode isthe weakest one of all implementations of the interface.

2.5.3 Boot Sequence

When TinyOS is booting up, it uses 3 interfaces:

• Init

• Scheduler

• Boot

Init has only one command called init() which is implemented in Scheduler,PlatformInit and SoftwareInit. PlatformInit is execuded directly after Sched-uler initialization, wires to PlatformC and provides initializations which musthappen in a specific order. Components who do not directly depend on hard-ware resources should wire to SoftwareInit. If a specific initialization orderingis required, every component itself is responsible for establishing that order.Finally, Boot signals the completion of the bootup-process to the application.

7

2 TinyOS 2.5 TinyOS Internals

2.5.4 Ressource Arbitration

One major task of every operating system is the management of available re-sources, like communication interfaces that are used by different components.TinyOS distinguishes between 3 different kinds of abstractions:

• dedicated resources

• virtualized resources

• shared resources

A dedicated resource is a resource which is allocated by one and only onesubsystem all the time. Obvious, no sharing policy is needed here. Examplesfor such resources are counters and interrupts.

Virtualized resources are used by multiple clients through software virtu-alization. Here, every client interacts like using a dedicated reosource. Becausevirtualization is done in software, there is no upper bound on the numberof clients (apart from memory/efficiency constraints), with all virtualized in-stances being multiplexed on top of the underlying resource. Clearly, thisvirtualization goes along with cpu-overhead.

For example, this concept is used for timers on ATmega128-based platforms.Every time a new timer is instantiated, TinyOS builds a virtual timer on topof one physical timer.

The shared resource concept is used for modules that need exclusive accessto a resource for some time. An arbiter is responsible for multiplexing betweenthe different clients that want to use the resource. As long as a client holds aresource, it has complete access to it. TinyOS arbiters assume that clients arecooperative, that means that a client only acquires a resource when needed,and only holds it as long as needed, releasing it as soon as possible. No conceptof preemption is used here, so when client B needs a resource he cannot forceClient A to release it.

The arbiter, the centralized place that knows whether a resource is busy ornot, is an interface that must be instantiated by every client that wants touse the resource. After that, the client can request the resource. The requestis queued by the arbiter if the resource is busy. As soon as the resource isavailable, a special event “granted” is signaled to the client, who has nowexclusive access to it. It is the client’s responsibility to release it so soon aspossible. To avoid monopolizing a resource a request for a resource is onlyqueued if there is no other request of this client queued yet. It is also possibleto issue an “ImmediateRequest” command. If available the resource is grantedwithout an event, otherwise an error code is returned.

8

2 TinyOS 2.5 TinyOS Internals

An example for such a shared resource would be a bus, for example SPI asshown in codelistings 2.1 and 2.2. This listings are part of an implementationfor sending and receiving IEEE8023 - frames with an 10MBit ENC28J60 chip.A microcontroller can communicate with this chip by SPI. Given that at leastone other component could need independent access to SPI too, IEEE8023C re-quests the bus whenever data has to be exchanged between the microcontrollerand the ethernet chip. Once the resource SPI is available, the arbiter signalsthis to IEEE8023C, which has implemented the proper handler for this situ-ation, named Resource.granted(). After this handler was called, IEEE8023Cis in full control of the SPI bus, regardless of other components that may beusing SPI too. After finishing it’s work, IEEE8023C MUST free the resourceby calling Resouce.release(). From this time on, other components can use theresource.

Listing 2.1: IEEE8023P.nc#inc lude ”IEEE8023 . h”

module IEEE8023P{

prov ides i n t e r f a c e IEEE8023 ;uses i n t e r f a c e GeneralIO as ssMMC;uses i n t e r f a c e GeneralIO as ssETH ;uses i n t e r f a c e GeneralIO as rstETH ;uses i n t e r f a c e HplAtm128Interrupt as intETH ;uses i n t e r f a c e SpiByte ;uses i n t e r f a c e Resource ;

}

implementation{

command u in t 8 t IEEE8023 . i n i t ( ){

/∗. . . unimportant code i s not shown here . . .

∗/

/∗queue a reque s t f o r t h i s r e s ou r c e now . . .

∗/i f ( c a l l Resource . r eque s t ( ) == FAIL){

r e turn FAIL ;}e l s e{

stateETH = IEEE8023 INITIALIZING ;re turn SUCCESS;

}}

/∗eventhandler w i l l be c a l l e d when reque s t was queued andr e sou r c e becomes a v a i l a b l e

∗/event void Resource . granted ( void )

9

2 TinyOS 2.5 TinyOS Internals

{/∗

we are now in f u l l c on t r o l o f the r e s ou r c eread / wr i t e data to r e s ou r c e

∗/

c a l l Resource . r e l e a s e ( ) ;/∗

NO MORE acc e s s to the r e s ou r c e nowqueue another r eque s t to get in c on t r o l again

∗/}

}

Listing 2.2: IEEE8023C.ncc on f i gu r a t i on IEEE8023C{

prov ides i n t e r f a c e IEEE8023 ;}

implementation{

components IEEE8023P ;components Atm128SpiC as SPI ;

IEEE8023 = IEEE8023P ;IEEE8023P . SpiByte −> SPI . SpiByte ;IEEE8023P . Resource −> SPI . Resource [ 0 ] ;

/∗unimportant components and wir ing not shown here

∗/

}

10

3 nesC

3.1 Fundamental Programming Hints

Before diving into this C - dialect, the most important programming hints arelisted, as given in [Lev]

• It’s dangerous to signal events from commands, as you might cause a verylong call loop, corrupt memory and crash your program.

• Keep tasks short.

• Keep code synchronous when you can. Code should be async only if itstiming is very important or if it might be used by something whose timingis important.

• Keep atomic sections short, and have as few of them as possible. Becareful about calling out to other components from within an atomicsection.

• Only one component should be able to modify a pointer’s data at anytime. In the best case, only one component should be storing the pointerat any time.

• Allocate all state in components. If your application requirements neces-sitate a dynamic memory pool, encapsulate it in a component and try tolimit the set of users.

• Conserve memory by using enums rather than const variables for integerconstants, and don’t declare variables with an enum type.

• In the top-level configuration of a software abstraction, auto-wire Init toMainC. This removes the burden of wiring Init from the programmer,which removes unnecessary work from the boot sequence and removesthe possibility of bugs from forgetting to wire.

• If a component is a usable abstraction by itself, its name should endwith C. If it is intended to be an internal and private part of a largerabstraction, its name should end with P. Never wire to P componentsfrom outside your package (directory).

• Use the as keyword liberally.

11

3 nesC 3.2 Namespace, Components, and Interfaces

• Never ignore combine warnings.

• If a function has an argument which is one of a small number of con-stants, consider defining it as a few separate functions to prevent bugs.If the functions of an interface all have an argument that’s almost alwaysa constant within a large range, consider using a parameterized interfaceto save code space. If the functions of an interface all have an argumentthat’s a constant within a large range but only certain valid values, imple-ment it as a parameterized interface but expose it as individual interfaces,to both minimize code size and prevent bugs.

• If a component depends on unique, then #define a string to use in aheader file, to prevent bugs from string typos.

• Never, ever use the ’packed’ attribute.

• Always use platform independent types when defining message formats.

• If you have to perform significant computation on a platform indepen-dent type or access it many (hundreds or more) times, then temporarilycopying it to a native type can be a good idea.

3.2 Namespace, Components, and Interfaces

nesC applications consist of components that get wired together. A componentcan be a configuration or a module. Modules implement some functionality,while configurations describe how components are put together.

nesC uses a purely local namespace. This means that a component has todeclare all the functions it calls. An advantage in this approach is that allthe functions that get called are known at compile time - no RAM is usedfor storing function pointers, and no runtime allocation is required. This ispossible because of the nature of nesC - applications: this applications run onembedded systems with well-defined and tightly specified uses, and it is muchmore important to save memory than to provide flexibility by dynamic linking.

This declaration is done in the specification of the component. In this code-block, the component declares what functions it provides and what functionsit uses. This would be such a specification:

module doSomethingC {prov ides command <re turnva lue> prov idedFunct i ona l i ty (<arguments >);uses command <re turnva lue> usedFunct i ona l i ty (<arguments >);

}

In practice, instead of declaring the individual functions, a component spec-ifies what interfaces are used and provided. When specifying that a certaininterface is used, the component can use or call all of the functions that are

12

3 nesC 3.2 Namespace, Components, and Interfaces

implemented by this interface. As this functions can be implemented by differ-ent components in different ways, a configuration is needed: there, the callingcomponent is connected to another component that provides the needed func-tions through it’s interfaces. This action is called wiring.

Consider this code example, taken from the TinyOS powermanagement sub-system:

i n t e r f a c e StdControl {command e r r o r t s t a r t ( ) ;command e r r o r t stop ( ) ;

}

This interface named StdControl is used by components that need to turnoff or on other components, while StdControl is provided by components thatrepresent an abstraction or a service.

For example, it should be possible to enable and disable UART-transmission.So, the UART-module provides the interface StdControl. Mind the keywordas in the following code snippet. This keyword just renames the interface forlocal use and can be ommited.

module HplAtm128UartP {. . .

p rov ide s i n t e r f a c e StdControl as Uart0TxControl ;. . .}

The actual work is done in the module’s implementation. Keep in mind thatthe module providing an interface MUST implement all of the commands ofthe interface:

. . .

command e r r o r t Uart0TxControl . s t a r t ( ) {SET BIT(UCSR0B, TXEN) ;c a l l McuPowerState . update ( ) ;return SUCCESS;

}

command e r r o r t Uart0TxControl . s top ( ) {CLR BIT(UCSR0B, TXEN) ;c a l l McuPowerState . update ( ) ;return SUCCESS;

}

. . .

The next listing shows how wiring works:

c on f i gu r a t i on Atm128Uart0C {prov ides i n t e r f a c e StdControl ;

. . .}

implementation {

13

3 nesC 3.2 Namespace, Components, and Interfaces

components new Atm128UartP ( ) as UartP ;StdControl = UartP ;UartByte = UartP ;UartStream = UartP ;UartP . Counter = Counter ;

components HplAtm128UartC as HplUartC ;UartP . HplUartTxControl −> HplUartC . Uart0TxControl ;. . .

}

So, every higher-level component can switch on and off transmission on theUart0 interface, and the implementation also notifies the system that somehardware was started or stopped, an information that is used by the power-manangement system, as described earlier. Codelisting 3.1 demonstrates howan application can make use of such an interface.

At first, we define what components we want to use, and how they areput(wired) together.

Listing 3.1: MyPowersavingAppC.nc/∗ tab :4

Harald Glanzer , 0727156 TU Wien

Boot hardware , and turn on UART0 − TX when system i s up

t h i s program uses the g iven components MainC and Atm128Uart0Ccomponent ’MyPowersavingC ’ i s the app i t s e l f

∗/

c on f i gu r a t i on MyPowersavingAppC{}implementation{

components MainC ;components Atm128Uart0C ;components MyPowersavingC ;

/∗wire our app to the i n t e r f a c e ’Boot ’t h i s i n t e r f a c e i s prov ided by component ’MainC ’∗/MyPowersavingC −> MainC . Boot ;

/∗wire our app to the i n t e r f a c e ’ StdContro l ’t h i s i n t e r f a c e i s prov ided by component ’Atm128Uart0C ’∗/MyPowersavingC −> Atm128Uart0C . StdControl ;

}

After that, we can use the interfaces provided by the used components. Seelisting 3.2 for how that works.

Listing 3.2: MyPowersavingC.nc/∗

14

3 nesC 3.3 Tasks

Harald Glanzer , 0727156 TU Wien

i n t e r f a c e ’Boot ’ p rov ides the event ’ boo t e t ’ to us ,which MUST BE implemented by the user o f ’ Boot ’

Add i t i ona l l y , we are us ing the gener i c i n t e r f a c e StdContro lt h i s i n t e r f a c e i s prov ided by var ious components − t h i s appuses the i n t e r f a c e prov ided by ’Atm128Uart0C ’ , so we canenab le / d i s a b l e TX for UART0

see f i l e MyPowersavingAppC . nc fo r how the wir ing works∗/

module MyPowersavingC @safe ( ){

uses i n t e r f a c e Boot ;uses i n t e r f a c e StdControl ;

}implementation{

/∗when system has ’ boo t e t ’ up , we w i l l r e c e i v e t h i s event andcan take over from here . . .∗/event void Boot . booted ( ){

c a l l StdControl . s t a r t ( ) ;}

}

Any Application can be easily ported to another Platform by just rewiringthe Components, as long as all the interfaces are provided.

3.3 Tasks

In TinyOS, a module can post a task to the scheduler, which will get executedat some point later. Because a task is a deferred procedure call, there is noreturn value. Additionally, there are no parameters for tasks, though it ispossible to write an own implementation of the task interface. A declarationof a task has this form:

task void ch e ck In t e r r up t f l a g ( ) ;

Adding this task to the scheduler is done by the post keyword:

post ch e ck In t e r r up t f l a g ( ) ;

Tasks are non-preemptive, in other words, no task will ever get interruptedby the TinyOS scheduler. The advantage is that the programmer never has toworry about tasks corrupting each other’s data. On the other hand, tasks nevershould be too long because otherwise other tasks maybe could get delayed. So,a task that has to do long computations should be broken into multiple tasks.

15

3 nesC 3.4 Async Functions

TinyOS needs about 80 microcontroller clock cycles to post and execute atask, so there’s a tradeoff between lots of short tasks and fewer, but longerrunning tasks - no hard rule can be given here.

3.4 Async Functions

As stated before, a task will always run until it has finished. This is not trueunder all circumstances, because a task can be disrupted by an interrupt. Suchfunctions that run preemptively, triggered by an interrupt and from outside thetask context, are labeled with the async keyword. Consequently, all commandsthat are called and all events that get signalled by such functions are async aswell and must be marked async too.

To get an async function into a syncronous context, the only way possible isby using tasks. For example, receiving UART bytes will normally be done inter-rupt driven, so the corresponding interrupt vector will be called asyncronously.If the received data is handled by a higher level component in a syncronousfunction, the interrupt handler can post a task to get from the asyncronousinterrupt context to a syncronous task context.

3.5 Split-Phase Interfaces

As stated before, it should be possible in TinyOS to build a certain function-ality either in software or in hardware. Because hardware is almost alwaysnon-blocking, the software must be non-blocking as well to guarantee this ex-changeability. A traditional approach for solving this problem is to use multiplethreads: one thread requests an operation and is then put on a waiting queue,and another thread continues with some other work. The waiting thread is wo-ken up as soon as the operation has finished and interrupts the other runningthread.

A problem with threads is that they need RAM – a resource that is veryprecious on embedded systems. Every thread has it’s own private stack thathas to be untouched as long as the thread is suspended, so this part of memoryis wasted storage.

So, instead of threads, TinyOS uses the split-phase model: A program thatwants to execute some functionality (sampling a sensor; sending a data packet)requests the operation, returning immediatly afterwards. When the operationhas finished, this new state is signaled to the requester by an event. This isan important aspect of split-phase interfaces: They are bidirectional. There is

16

3 nesC 3.6 Generic Components

a downcall – generally a command – that starts an operation and the corre-sponding upcall, or event, to signal the completion.

The following code snippet gives an example for such an interface:

i n t e r f a c e Send {command e r r o r t send ( message t ∗ msg , u i n t 8 t l en ) ;event void sendDone ( message t ∗ msg , e r r o r t e r r o r ) ;command e r r o r t cance l ( message t ∗ msg ) ;command void∗ getPayload ( message t ∗ msg ) ;command u in t 8 t maxPayloadLength ( message t ∗ msg ) ;

}

A component that uses such a (split-phase) interface MUST implement allof the events. So, a higher-level component that wants to make use of theSend interface by calling the send function must implement an event calledsendDone, that will be signalled by the send function.

When using split-phase interfaces, it is important to remember the first pro-gramming hint: Signaling events from commands is dangerous, because thiscan cause long call loops or corrupt memory caused by exploding stack size.So instead of using commands, the correct way is to use tasks.

3.6 Generic Components

In TinyOS components are singletons, every configuration that names a com-ponent names the same component. Generic components can have multipleinstances, and essentially provide a new copy with the parameter values substi-tuted every time they are instantiated. While this leads to increased executablecode, it decreases the source code and improves code readabibility.

Generic components have the keyword generic before their signature and areintantiated with the keyword new. The following examples are based on codesnippets from [Lev]:

Listing 3.3: Generic Moduleg ene r i c module BitVectorC ( u in t 16 t max bits ) {

prov ides i n t e r f a c e I n i t ;p rov ide s i n t e r f a c e BitVector ;

}implementation {

u i n t 8 t b i t s [ ( max bits + 7) / 8 ] ;. . .

}

Listing 3.4: Generic Configurationg ene r i c c on f i gu r a t i on ExampleVectorC ( u in t 16 t max bits ) {

. . .p rov ide s i n t e r f a c e BitVector as Bit s8 ;p rov ide s i n t e r f a c e BitVector as Bit s2 ;

17

3 nesC 3.7 Parameterized Interfaces and Configurations

prov ides i n t e r f a c e BitVector as Bit s3 ;}implementation {

components new BitVectorC (8) as BV1;components new BitVectorC (10) as BV2;components new BitVectorC ( max bits ) as BV3;

. . .

B i t s1 = BV1;Bit s2 = BV2;Bit s3 = BV3;

}

Listing 3.4 generates 3 instances of BitVectorC, where BV3 is set to the valueof max bits which is defined at the instantiation of the configuration.

Without generic components it would be necessary to write different modulesfor all the max bits values.

3.7 Parameterized Interfaces and Configurations

We have seen one way of providing independent instances in the last section inform of generalization. In some applications however this approach has somedrawbacks. For example when listening to UDP Packets on different Ports.

It would be possible to implement a generic interface leading to configurationslike

components new UdpReceive (UDP PORT A) as Receive1 ;components new UdpReceive (UDP PORT B) as Receive2 ;

but this would mean unnecessary code repeation and also force the caller topass the argument as a run-time parameter.

Parameterized interfaces are in essence an array of interfaces and look asfollowed:i n t e r f a c e UdpReceive {

event void r e c e i v ed ( i n add r t ∗ s rc Ip , u i n t 16 t srcPort ,u i n t 8 t ∗data , u i n t 16 t l en ) ;

}

module UdpTransceiverP {<...>

prov ides i n t e r f a c e UdpReceive [ u i n t 16 t port ] ;<...>

}implementation {

<...>default event void UdpReceive . r e c e i v ed [ u i n t 16 t port ] ( i n add r t ∗ s rc Ip ,

u i n t 16 t srcPort , u i n t 8 t ∗data , u i n t 16 t l en ) {<...>

}<...>}

18

3 nesC 3.8 Wiring

providing us with 65535 possible different receivers.

3.8 Wiring

As said before, in nesC a component can only call functions and access variableswhithin its local namespace. To call functions outside it’s scope, a set of namesin one component, generally an interface, must be mapped to a set of namesin another component. This operation is called wiring.

3.8.1 Modules vs. Configurations

Components can either be Modules or Configurations – both use and provideinterfaces. This set of used and provided interfaces defines the signature of thecomponent.

The difference between Modules and Configurations lies in their implemen-tation: while configurations are implemented by other components, which theywire, modules are executable code. Modules are written for the most part instandard - C.

3.8.2 Wiring-Operators

There are 3 operators for wiring components together:

• <-

• ->

• =

The first two operators are interchangeable, for example this two lines areidentical:

MyComponent . Used Inte r f ace −> OtherComponent . Prov ided In t e r f a c e ;OtherComponent . Prov ided In t e r f a c e <− MyComponent . Used Inte r f ace ;

In short, the arrow always points from the user of an interface to the providerof that interface:

User −> Provider ;

As soon as MyComponent is connected this way to OtherComponent, My-Component can use all of the functions provided by ProvidedInterface. Ad-ditionally, UsedInterface MUST implement all the handlers OtherComponentoffers events for.

19

3 nesC 3.8 Wiring

If MyComponent wants to call a function provided by OtherComponent, thecall would look like this:

c a l l Used Inte r f ace . FunctionName(<argument l i s t >);

To implement the handler for the events that can be signaled by Provided-Interface, a construct of this form in UsedInterface is neccessary:

event <returntype> UsedInte r f ace . EventName(<argument l i s t >){

/∗code to handle the new s i t ua t i on , as s i g n a l l e d by t h i s event∗/

}

The third operator ’=’ exports an interface. It defines how the configurationof an interface is implemented, by delegating it to another component. Incontrast, the ’arrow’ - operator combines components that already exist.

Listing 3.5: GlcdC.nc/∗∗∗ High l e v e l implementation fo r KS0108 Glcd∗ @author : Markus Hartmann e988811@student . tuwien . ac . at∗ @date : 01.02.2012∗/

c on f i gu r a t i on GlcdC{

prov ides i n t e r f a c e Glcd ;}

implementation{

components MainC ;components GlcdP ;components HplKS0108C ;

Glcd = GlcdP . Glcd ;GlcdP . Hpl −> HplKS0108C ;MainC . So f twa r e In i t −> GlcdP . I n i t ;

}

The difference is explained on the basis of codelisting 3.5, the top-level con-figuration for a component that provides functionality for a graphical display.This component provides the interface Glcd which can be used by a high-levelprogrammer to easily use such a display. GlcdC consists of the private com-ponent GlcdP and uses the interface HPL provided by HplKS0108C and Initprovided by MainC. Glcd is an interface of the configuration itself, implementedin the component GlcdP and mapped to by using “=”. The interface Glcd getsexported by the configuration so that other, higher-level components can usethis interface by specifying that component GlcdC with interface Glcd is used.

Opposite to that, component HplKS0108C is used “inside” to get the workdone (hidden from the user of GlcdC, no functionality is exported to a higher

20

3 nesC 3.8 Wiring

level). GlcdC wires itself to the SoftwareInit interface from MainC, which callesthe init() function after startup.

21

4 MicroC/OS-II

To emphasize the characteristics of TinyOS, another OS called OS-II is pre-sented. The MicroC kernel was developed by Jean J. Labrosse.

4.1 Basics

MicroC/OS-II is a portable, ROMable, scalable preemptive real-time multitask-ing kernel, written in ANSI-C. Small portions of the sourcecode are written inassembler to adapt to different processor architectures. MicroC/OS-II is basedon MicroC/OS, also called The Real Time Kernel, which was published in 1992.MicroC/OS v1.11 is compatible to its successor.

MicroC/OS-II is used in all kinds of embedded systems, ranging from enginecontrols to audio equiment.

Important characteristics of this real-time multitasking OS are:

• Scaleable, with a minimum RAM footprint of 6KByte

• Maximum RAM footprint 24KByte

• Preemptive scheduler

• 10 Kernel services

• 80 System calls

• Support for semaphores

• Support for event flags

• Support for message queues

• Support for message mailboxes

• Up to 250 application tasks

• Constant / deterministic execution time for most services provided

• Support for large number of processor architectures

• Supported processors range from 8bit to 64bit architectures

• Supports multi-threaded applications

22

4 MicroC/OS-II 4.2 Differences TinyOS - MicroC/OS-II

4.2 Differences TinyOS - MicroC/OS-II

4.2.1 Real-Time

A real-time system is a system where not only the correctness of a calculation isimportant, but also the instant when this calculation was finished. The mostimport features of a real-time kernel are minimal and predictable interruptlatency and task switching latency.

While MicroC/OS-II supports a timely determinstic behaviour, no such as-sertion can be given for TinyOS.

4.2.2 Scheduler

MicroC/OS-II has a preemptive scheduler – that means that every task getsonly a limited time for using the CPU. The time a task gets for execution alsodepends on the task’s priority – all tasks MUST have different priorities –because otherwise additional round-robin scheduling or similar would be nec-essary to handle tasks with equal priority. More important tasks get higherpriority.

A task can be in 5 different states, as shown in figure 4.1:

Figure 4.1: Statemachine for Tasks

• Dormant: task is loaded in memory but not ready to run yet

• Ready: task is ready to run, but higher-priority task is running at themoment

• Running: task is in control of the CPU

• ISR: interrupt has occured, CPU is executing ISR instead of task

• Waiting: task waits for an event (completion of IO operation, ...)

23

4 MicroC/OS-II 4.2 Differences TinyOS - MicroC/OS-II

In contrast, TinyOS knows only 3 states:

• Queued: task is queued, but a sooner queued task is running at themoment

• Running: task is in control of the CPU

• ISR: interrupt has occured, CPU is executing ISR instead of task

Also, as already said, TinyOS uses a non-preemptive scheduler - see Chap-ter 2 for details.

TinyOS also provides a thread library called TOSThreads which supportspreempitve applocation level threads. However, this library has not been portedfor the bigAVR6 or bigAVR6 1280 platform.

4.2.3 Mutual Exclusion

Whenever different tasks need to share data with each other, some points mustbe ensured to avoid data corruption and resource contention. Problems arise,for example, if task A gets scheduled and accesses a data element that is alsoneeded by task B. If task A gets preempted by task B before task A’s calcula-tions are finished, task B works on incomplete data, possibly invalidating it’scalculations. To prevent such situations, MicroC/OS-II provides the followingmechanisms:

• Disabling/Enabling of interrupts with macros

• Semaphores

By disabling interrupts, a task or ISR can assure that it won’t get preemptedby an ISR or by a task, so this is an easy way to grant mutual exclusion.Drawbacks of this solution are that the system obviously can’t react to other,possibly important, interrupts. Additionally, because the Micro/OS-II kerneluses timeslicing, the task scheduler is deactivated because no timer interruptsare handled. Therefore, a badly designed task can halt the whole system if itenters a deadlock or some kind of infinite loop.

Semaphores, developed by Edsger W. Dijkstra, are software constructs thatcan be used for the same goal. Additionally, they can be used for syncronizingtasks, as described in the following section.

Because TinyOS uses a non-preemptive scheduler, no such constructs arenecessary. Because a task cannot get suspended (apart from an interrupt) byanother task, every task is responsible to keep it’s data in a consistent state.

24

4 MicroC/OS-II 4.2 Differences TinyOS - MicroC/OS-II

4.2.4 Intertask Communication

The process of sharing data between different tasks or ISRs is called inter-task communication. Therefore, MicroC/OS-II supports the following ways ofsharing data between tasks

• Message Mailboxes

• Message Queues

MircoC/OS-II provides kernel services to send messages by depositing apointer variable into a task’s mailbox. A task that expects such a messageis suspended and put onto a waitinglist. If the message arrives within a time-out, the highest-priority task that is waiting for the message is woken up.

A message queue is basically an array of such message mailboxes.

In TinyOS, a task can share data by sharing a pointer or by passing a pa-rameter (if supported by the used Task interface).

4.2.5 Task Synchronisation

• Semaphores

• Event Flags

Aside from using semaphores for granting mutual exclusion, this softwareconstructs can also be used to synchronize a task with an ISR or other tasks.Additionally, MicroC/OS-II offers kernel services to set, clear and wait forevent flags.

Syncronisation in TinyOS is implemented by events.

4.2.6 Memory Footprint

When using a kernel to manage tasks, the total memory that is needed consistsof the application code size + the kernel code size. A minimum ram footprintof 6kByte is given by the developer of MicroC/OS-II.

25

5 bigAVR6

5.1 The Hardware

This development board, as shown in Figure 5.1, is produced by mikroElek-tronika and supports 64- and 100-pin AVR TQFP packages.

5.1.1 Onboard - Features

• 2 x UART

• high-speed CAN transceiver MCP2551

• USB 2.0 (if supported by MCU)

• MMC/SD card slot

• digital thermometer DS1820

• onboard USB 2.0 programmer

• real-time clock DS1307

• 86 LEDs to indicate logic state of all microcontroller-pins

• 86 push buttons to control microcontroller digital inputs

• IDC10 connectors for all microcontroller pins

• DIP - switches to separate port pins from pull-up/down resistors

• potentiometer for testing the ADC - channels

• 1KBit serial EEPROM 24AA01

5.1.2 Extensions

• 2x16 Character LCD, directly connectable via on-boad connectors

• 64x128 GLCD with touchscreen foil, directly connectable via on-boadconnectors

• IEEE802.3 extensionboard 10MBit

• SmartMP3 decoder board

• ...

26

5 bigAVR6 5.2 Supported Modules

Figure 5.1: bigAVR6 platform, [Mika]

5.2 Supported Modules

5.2.1 Character LCD 2x16

A 2x16 alphanumeric LCD module is available for displaying ASCII - charac-ters. The display backlight can be turned on with switch SW15/8, as shown inschematic 5.2, the brightness can be adjusted with potentiometer P1

Figure 5.2: LCD 2x16, [Mika]

The logic level of the following pins MUST NOT be touched by the pro-grammer when using the LCD2x16:

27

5 bigAVR6 5.2 Supported Modules

• PORT C: PC2, PC3, PC4, PC5, PC6, PC7,

To use the LCD, component BufferedLcdC with interface BufferedLcd canbe used. The display initializes itself by wiring to MainC.SoftwareInit. Seelisting 5.1 for the available commands. After initializing, data can be writtento the LCD memory, and the display is updated by calling forceRefresh(). Acommand autoRefresh(uint32 t period) is provided which will start a timer andcall forceRefresh() every period milliseconds. It should be noticed that once-written data is preserved unless the corresponding position is overwritten bynew text or the display is cleared.

Listing 5.1: BufferedLcd.nc/∗∗∗ @author : Andreas Hagmann <ahagmann@ecs . tuwien . ac . at>∗ @date : 22.01.2012∗/

#include <avr /pgmspace . h>

i n t e r f a c e BufferedLcd {/∗∗∗ @param per iod r e f r e s h per iod in ms, s e t to 0 to d i s a b l e auto r e f r e s h∗/

command void autoRefresh ( u in t 32 t per iod ) ;command void c l e a r ( ) ;command void wr i t e (char ∗ s t r i n g ) ;command void write P ( const char ∗ s t r i n g ) ;command void goTo( u i n t 8 t l i n e , u i n t 8 t c o l ) ;command void f o r c eRe f r e sh ( ) ;

}

When examing schematic 5.2, one can see that there is a design flaw existing:pin RW is bound to GND. Because of this (low=write operation), no readoperation is possible. Accordingly, it is not possible to read the correspondingregister to determine whether a write-operation has already finished. To handlethis problem and give the LCD controller enough time to process a write-operation(needed for initializing, clearing the display and writing characters toit), there are two options:

• use busywaiting - blocking

• use a timer - non-blocking

With the first solution - busy waiting - the time to wait can be minimizedto the absolutely necessary time, but obviously the time spent in the spinloopis lost cpu time, which is bad.

The second solution - using the generic timer interface TimerMilliC - doesn’twaste cpu time(apart from the extratime spent in the timer’s interrupt vector),but problematic about this solution is that the existing timer-framework doesn’tprovide good granularity. The minimal periodic time that can be achieved

28

5 bigAVR6 5.2 Supported Modules

is about 20msec, which is hereby the waiting time for every character whensending a string to the display. While this is not problematic when initializingor clearing the display, a considerable delay is introduced when text is writtento the display.

The interface provided uses busy waiting to write a single character. Tominimize the time while refreshing the display, only changed lines are rewritten.

5.2.2 GLCD

The GLCD extension consists of a KS0108B GLCD dot matrix liquid crystalgraphic display with a resolution of 128 x 64 pixel. As the schematics show inFigure 5.3, SW15/8 must be turned on to activate the GLCD-backlight, thecontrast can be changed with potentiometer P3.

The logic level of the following pins MUST NOT be touched by the pro-grammer when using the GLCD and the touchscreen:

• PORT A: all ports reserved for GLCD

• PORT E: PE2, PE3, PE4, PE5, PE6, PE7 reserved for GLCD

• PORT F: PF0, PF1 reserved for touchscreen

• PORT G: PG3, PG4 reserved for touchscreen

Figure 5.3: GLCD schematics, [Mika]

To use the GLCD in an application, component GlcdC with interface Glcdcan be used. This interface (as shown in lising 5.2) provides high-level functions

29

5 bigAVR6 5.2 Supported Modules

for writing and drawing objects such as dots, rectangles and circles. GlcdC itselfis wired to HplKS0108C for low-level functions and to MainC.SoftwareInit. Thelatter ensures that the hardware is initialized properly without any necessaryaction on the users side.

Listing 5.2: Glcd.nc/∗∗∗ High l e v e l i n t e r f a c e f o r KS0108 GLCD Disp lay∗ @author : Markus Hartmann e988811@student . tuwien . ac . at∗ @date : 01.02.2012∗/

#include ”KS0108 . h”

i n t e r f a c e Glcd{

/∗∗∗ Set p i x e l∗∗ @param x−coord inate∗ @param y−coord inate∗∗ @return SUCCESS∗∗/

command e r r o r t s e tP i x e l ( const u i n t 8 t x , const u i n t 8 t y ) ;

/∗∗∗ Clear p i x e l∗∗ @param x−coord inate∗ @param y−coord inate∗∗ @return SUCCESS∗∗/

command e r r o r t c l e a rP i x e l ( const u i n t 8 t x , const u i n t 8 t y ) ;

/∗∗∗ Inve r t p i x e l∗∗ @param x−coord inate∗ @param y−coord inate∗∗ @return SUCCESS∗∗/

command e r r o r t i n v e r tP i x e l ( const u i n t 8 t x , const u i n t 8 t y ) ;

/∗∗∗ Draw l i n e∗∗ @param f i r s t po in t x∗ @param f i r s t po in t y∗ @param second po in t x∗ @param second po in t y∗∗ @return SUCCESS∗∗/

30

5 bigAVR6 5.2 Supported Modules

command e r r o r t drawLine ( const u i n t 8 t x1 , const u i n t 8 t y1 ,const u i n t 8 t x2 , const u i n t 8 t y2 ) ;

/∗∗∗ Draw rec t ang l e∗∗ @param upper l e f t x∗ @param upper l e f t y∗ @param lower r i g h t x∗ @param lower r i g h t y∗∗ @return SUCCESS∗∗/

command e r r o r t drawRect ( const u i n t 8 t x1 , const u i n t 8 t y1 ,const u i n t 8 t x2 , const u i n t 8 t y2 ) ;

/∗∗∗ Draw e l l i p s e∗∗ @param center x∗ @param center y∗ @param rad ius ho r i z on t a l∗ @param rad ius v e r t i c a l∗∗ @return SUCCESS∗∗/

command e r r o r t drawEl l ip se ( const u i n t 8 t x , const u i n t 8 t y ,const u i n t 8 t rad ius h , const u i n t 8 t r ad iu s v ) ;

/∗∗∗ F i l l Disp lay with pa t t e rn∗∗ @param pat t e rn∗∗ @return SUCCESS∗∗/

command e r r o r t f i l l ( u i n t 8 t pattern ) ;

/∗∗∗ drawText∗∗ @param t e x t∗ @param x−coord inate o f lower l e f t edge∗ @param y−coord inate o f lower l e f t edge∗∗ @return SUCCESS∗∗/

command void drawText ( const char ∗ text , const u i n t 8 t x , const u i n t 8 t y ) ;

}

5.2.3 Touch Screen

The GLCD is combined with a touchscreen foil, sticked onto the GLCD-surface.Activate SW13/1,2,3,4 to use it. The internal low-level module HplTouchScreen

31

5 bigAVR6 5.2 Supported Modules

uses ADC channels 0 and 1 to detect pressure. Interface TouchScreen (List-ing 5.3) provides commands to request coordinates and to calibrate the Screen.As shown in Figure 5.4 interface Glcd is already provided by TouchScreen, andcan be used without utilizing component GlcdC directly.

TouchScreenDemoC . TouchScreen −> TouchScreenC . TouchScreen ;TouchScreenDemoC . Glcd −> TouchScreenC . Glcd ;

Figure 5.4: TouchScreen components

Listing 5.3: TouchScreen.nc/∗∗∗ I n t e r f a c e f o r TouchScreen∗ @author : Markus Hartmann e988811@student . tuwien . ac . at∗ @date : 13.02.2012∗/

#include ”TouchScreen . h”

i n t e r f a c e TouchScreen{

/∗∗∗∗ @param x o f f s e t∗ @param y o f f s e t∗∗ @return SUCCESS∗/

command e r r o r t c a l i b r a t e ( i n t 8 t x o f f s e t , i n t 8 t y o f f s e t ) ;

/∗∗∗∗ @param po in t e r to b u f f e r f o r coord ina te s∗

32

5 bigAVR6 5.2 Supported Modules

∗ @return SUCCESS i f r e que s t was accepted∗ EBUSY i f another r eque s t i s pending∗/

command e r r o r t getCoord inates ( t s c o o r d i n a t e s t ∗xy ) ;

/∗∗∗ No t i f i c a t i o n tha t coord ina te s are ready∗∗/

event void coordinatesReady (void ) ;}

5.2.4 MMC

A MMC/SD connector is available onboard so that memory cards can beinterfaced to the microcontroller via SPI. As shown in Figure 5.5, activateSW15/3/4/5/6/7 to use it. Because the memory card is powered with 3.3V,whereas the microcontroller needs 5V supply, a 74LVCC3245 bus transceiveris used to obtain the needed voltage levels.

The logic level of the following pins MUST NOT be touched by the pro-grammer when using the MMC:

• PORT B: PB1, PB2, PB3 reserved for MMC: SCK / MISO / MOSI

• PORT G: PG1, PG2 reserved for MMC: CS / CD

Figure 5.5: MMC/SD Schematics, [Mika]

Component SdcardC provides interface Sdcard to enable an application pro-grammer to easily read RAW - data from a MMC. No write functionality issupported yet. The available functions are shown in Listing 5.4.

To read data, init() must be called first to initialize the memorycard. Af-ter initialization the event initDone(error t) is signaled, indicating the currentstatus by the passed value error t. Afterwards, data can be read from thememorycard by calling

33

5 bigAVR6 5.2 Supported Modules

c a l l Sdcard . readBlock ( blockAddr , ∗ bu f f e r ) ;

After completion, event readBlockDone(uint8 t *buffer, error t error) is sig-naled to the application and data is available by a pointer, in units of 32 byteblocks.

Listing 5.4: Sdcard.nc/∗∗∗ @author : Andreas Hagmann <ahagmann@ecs . tuwien . ac . at>∗ @date : 12.03.2012∗∗ based on an implementation o f Harald Glanzer , 0727156 TU Wien∗/

i n t e r f a c e Sdcard {command e r r o r t i n i t ( ) ;event void in i tDone ( e r r o r t e r r o r ) ;command e r r o r t readBlock ( u i n t 32 t blockAddr , u i n t 8 t ∗ bu f f e r ) ;event void readBlockDone ( u i n t 8 t ∗ bu f f e r , e r r o r t e r r o r ) ;command bool i n s e r t e d ( ) ;

}

The following limitations are to be noticed:

• Read Only Access

• Raw data, no filesystem supported

• Data is always read in 32 byte blocks

5.2.5 MP3 extension board

The SmartMP3 extension board shown in Figure 5.6 consists of a VS1011edecoder chip and a SD card module. The card module can be used with com-ponent SdCardC as described in Section 5.2.4. CS, CD and MISO from theMMC module MUST be deactivated via SW15/4/6/7.

Figure 5.6: MP3 board, [Mika]

34

5 bigAVR6 5.2 Supported Modules

The board is connected via SPI, the maximum speed for reading registers is2MHZ (sufficiently below CLKI

6= 4, 1MHZ according to manual), the max-

imum for sending data 4MHZ. The module is wired to SoftwareInit for ini-tialization and provides high level functions with interface MP3 as shown inListing 5.5.

Listing 5.5: MP3.nc/∗∗∗ @author : Markus Hartmann <e9808811@student . tuwien . ac . at>∗ @date : 31.07.2012∗/

i n t e r f a c e MP3{

/∗∗∗ S tar t and s top s ine t e s t∗∗ @param on TRUE to s t a r t − FALSE to s top∗∗ @return SUCCESS i f command was s u c c e s s f u l l y sent over SPI∗/

command e r r o r t s ineTes t ( bool on ) ;

/∗∗∗ Set volume∗∗ @param volume Volume to be s e t∗∗ @return SUCCESS i f command was s u c c e s s f u l l y sent over SPI∗/

command e r r o r t setVolume ( u i n t 8 t volume ) ;

/∗∗∗ Send data∗∗ @param data A poin t to a data b u f f e r where the data i s s to red∗ @param len Length o f the message to be sent − data must be at l e a s t as l a r g e as l en∗∗ @return SUCCESS i f r e que s t was granted and sending the data s t a r t e d∗/

command e r r o r t sendData ( u i n t 8 t ∗data , u i n t 8 t l en ) ;

/∗∗∗ Check i f VS1011e i s ready to accept new data∗∗ @return FALSE i f VS1011e i s busy or sending o f data i s in progres s − o therwi se TRUE∗/

command bool isBusy ( void ) ;

/∗∗∗ Read decode time∗∗ @param data A poin t to a data b u f f e r where the decode time w i l l be s to red∗∗ @return SUCCESS i f command was s u c c e s s f u l l y sent over SPI∗/

command e r r o r t readTime ( u in t 16 t ∗ time ) ;

35

5 bigAVR6 5.2 Supported Modules

/∗∗∗ Set decode time∗∗ @param time The time to s e t∗∗ @return SUCCESS i f command was s u c c e s s f u l l y sent over SPI∗/

command e r r o r t setTime ( u in t 16 t time ) ;}

5.2.6 Ethernet board

Figure 5.7: Ethernet Board, [Mikb]

This extension board, shown in Figure 5.7, can be used for sending andreceiving IEEE802.3 frames, and therefore embedding the development boardinto a network. The board features an ethernet controller ENC28J60 thatexchanges data with a microcontroller via SPI. The board can be connected todsPIC, AVR-8051 and PIC by three 10-pin IDC connectors 1. The board needs3.3V voltage supply, but has a 74LVXc3245 bus transceiver chip for runningthe board with 5V logic levels. Therefore, jumper J1 has to be set correctly.

A basic UDP/IP/ARP stack has been implemented, with the following lim-itations:

• No UDP - level checksum

• No IP - level options

• No IP - level fragmentation

• ARP request/reply only

1Because MikroElektronika did not manage to make the pin layout compatible with thebigAVR6 board, it is necessary to use single pin connectors.

36

5 bigAVR6 5.2 Supported Modules

For using the extension board with the bigAVR6, the following requirementshave to be provided:

• Jumper J1 on the Ethernetboard must be set to 5V

• SPI-AVR-8051 VCC must be connected to 5V

• SPI-AVR-8051 GND must be connected to ground

• SPI-AVR-8051 CS must be connected to PORT B0

• SPI-AVR-8051 SCK must be connected to PORT B1

• SPI-AVR-8051 MOSI must be connected to PORT B2

• SPI-AVR-8051 MISO must be connected to PORT B3

• SPI-AVR-8051 RST must be connected to PORT B4

• SPI-AVR-8051 INT must be connected to PORT D0

Obviously, the state of this connected pins MUST NOT be touched by theprogrammer.

IMPORTANT NOTE

RS-232 Port B CAN NOT BE USED together with this componentbecause Port D, which is used as the external interrupt source from the ether-netboard, is also used as UART1(=RS-232 Port B) RX pin. Instead, RS-232Port A MUST be used if the UDP-services are also needed.

Also, jumper J21 MUST BE set to onboard programmer for IEEE8023Cto function!

The Ethernet Board module Enc28j60C uses Interface Mac, which is pro-vided by LlcTransceiverC and provides a control interface by itself. A completewiring example is shown in Listing 5.6 .

Listing 5.6: UdpAppC.nc/∗∗∗ @author : Andreas Hagmann <ahagmann@ecs . tuwien . ac . at>∗ @date : 12.12.2011∗/

#include ”debug . h”#include ” udp con f ig . h”

c on f i gu r a t i on UdpAppC {

}

implementation {components MainC ;components UdpDemoC;components new UdpC(UDP PORT) ;

#ifndef WLANcomponents Enc28j60C as EthernetC ;

37

5 bigAVR6 5.2 Supported Modules

#elsecomponents Mrf24wC as EthernetC ;

#endifcomponents new TimerMill iC ( ) as Timer ;components LlcTransce iverC ;components BufferedLcdC as LcdC ;components IpTransce iverC ;components StdoDebugC ;components PingC ;

UdpDemoC −> MainC . Boot ;UdpDemoC. UdpSend −> UdpC;UdpDemoC. UdpReceive −> UdpC;UdpDemoC. Control −> EthernetC ;UdpDemoC. Timer −> Timer ;LlcTransce iverC .Mac −> EthernetC ;UdpDemoC. IpContro l −> IpTransce iverC ;UdpDemoC. Lcd −> LcdC ;

#ifdef WLANUdpDemoC. WlanControl −> EthernetC ;

#endif}

When the application wants to send data to or receive data from a remotehost, it requests hardware control by calling the start function of the SplitControl interface. After receiving the event

void startDone ( e r r o r t e r r o r )

Data can be sent and received by using component UdpC which providesinterface UdpSend and UdpReceive, shown in 5.7 and 5.8.

Listing 5.7: UdpSend.nc/∗∗∗ @author : Andreas Hagmann <ahagmann@ecs . tuwien . ac . at>∗ @date : 12.12.2011∗∗ based on an implementation o f Harald Glanzer , 0727156 TU Wien∗/

#include ”udp . h”

i n t e r f a c e UdpSend {command e r r o r t send ( i n add r t ∗dstIp , u i n t 16 t dstPort , u i n t 8 t ∗data , u i n t 16 t l en ) ;event void sendDone ( e r r o r t e r r o r ) ;

}

Listing 5.8: UdpReceive.nc/∗∗∗ @author : Andreas Hagmann <ahagmann@ecs . tuwien . ac . at>∗ @date : 12.12.2011∗∗ based on an implementation o f Harald Glanzer , 0727156 TU Wien∗/

i n t e r f a c e UdpReceive {event void r e c e i v ed ( i n add r t ∗ s rc Ip , u i n t 16 t srcPort , u i n t 8 t ∗data , u i n t 16 t l en ) ;

}

38

5 bigAVR6 5.2 Supported Modules

Afterwards, the data is handed down the stack, as shown in Figure 5.8.At first, an UDP header is generated, and the payload, as assigned by theapplication, is attached to it. As mentioned above, NO checksum is generatedat this level - if needed, a checksum must be calculated at application level.This UDP packet(payload + UDP-header) is then handed to the next level,the IP level.

At this level, a checksum is generated, which includes the IP-header only. Inthe next step, a routing-decision has to be made: either the packet is addressedto a host inside the Network (the remote host has the same network-adress thanthe IP that has been assigned to the bigAVR6 board), or the packet must hopoutside. In the first case, the packet can be sent to the host directly, otherwise,it must be sent to the default gateway, which can be assigned with the IpControlinterface provided by IpTransceiverC as seen in 5.9. Note the ’,’ instead of theusual ’.’ between the numbers:

#de f i n e GATEWAY 192 ,168 ,0 ,1i n add r t cgw = { . bytes {GATEWAY}} ;c a l l IpContro l . setGateway(&cgw ) ;

Listing 5.9: IpControl.nc/∗∗∗ @author : Andreas Hagmann <ahagmann@ecs . tuwien . ac . at>∗ @date : 12.12.2011∗∗ based on an implementation o f Harald Glanzer , 0727156 TU Wien∗/

i n t e r f a c e IpContro l {command void s e t I p ( i n add r t ∗ ip ) ;command void setGateway ( i n add r t ∗gateway ) ;command void setNetmask ( i n add r t ∗netmask ) ;

command in add r t ∗ get Ip ( ) ;command in add r t ∗ getGateway ( ) ;command in add r t ∗ getNetmask ( ) ;

}

When the proper destination IP has been found, an ARP lookup is done ina cache. If no ARP entry is found for the destionation IP, a lookup is sentautomatically. Be aware that, if no MAC is found, the ARP-request triggeringpacket is lost and must be resent by the application. If the MAC is known, it isextracted from the MAC cache, and component IEEE802.3 takes over control,where the frameheader and the payload (data + udp-header + ip-header) iscopied into the transmit memory of the ENC28J60 by SPI. Afterwards, thecommunication is started, and the completion is signaled to the application.

The MAC address is calculated out of TOS NODE ID and can be set duringinstallation with

make <platform> i n s t a l l ,< id>

39

5 bigAVR6 5.2 Supported Modules

Note that there is no space after the comma!

To receive a packet from remote hosts, the packet must either has theproper destination MAC set, or must be a multicast frame(destination0xFFFFFFFFFFFF), otherwise the Ethernet controller chip ENC28J60 willnot accept it. If a valid MAC is present, the ENC28J60 will autonomouslycopy the packet into the receive buffer and signal completion by an interrupt.The packet will be read out by component Enc28j60C and handed over to theIP-level. If the packet is an ARP - request, a corresponding reply will be sent,otherwise the payload will be handed over one level higher, which is the UDP- level. Note that the IP-checksum will NOT be checked. At UDP level, theactual payload will get extracted and is handed over to the application.

Figure 5.8: UDP Stack

Network Sniffing

For testing purposes, the command line tool netcat can be used. As example,a constant string should be sent to the ip 192.168.1.100, destinationport 4443,as shown in the following listing.

. . .dstIP [ 0 ] = 192 ;dstIP [ 1 ] = 168 ;dstIP [ 2 ] = 1 ;

40

5 bigAVR6 5.2 Supported Modules

dstIP [ 3 ] = 100 ;c a l l UDP. sendData ( ( u i n t 16 t ∗) ” h e l l o world” , ( u i n t 8 t ∗) dstIP ,

80 , 4443 , s izeof ( ” h e l l o world” ) ) ;. . .

To receive the string on the corresponding host, this command line can beused:

nc −u − l 4443

This starts netcat in listening mode, specifies that UDP instead of TCPshould be used and that it should bind to port 4443. Port 4443 belongs to theso-called unprivileged ports, where a ’normal’, unpriviliged user can bind to.All ports greater thant 1023 belong to this group.

5.2.7 UART

There are 2 UART ports available onboard, RS-232 port A and port B. Compo-nent PlatformSerialC is wired to port A and provides the following interfaces:

• StdControl to start/stop the Hardware

• UartControl to set speed and mode

• UartByte to send a single byte

• UartStream to send a String

To use the UartStream interface, receive interrupt must be enabled by hand.

A short example for wiring:

components Plat formSer ia lC ;components UartC ;

UartC . UartControl −> Plat formSer ia lC ;UartC . UartStream −> Plat formSer ia lC ;

And sending and receiving data:

c a l l Uart . s t a r t ( ) ;c a l l UartControl . setSpeed (TOS UART 115200 ) ;c a l l UartControl . s e tPa r i t y (TOS UART PARITY NONE) ;

c a l l UartStream . send ( ( u i n t 8 t ∗) ”Hal lo Du!\n” , 1 0 ) ;c a l l UartStream . enab l eRece ive In t e r rupt ( ) ;c a l l UartStream . r e c e i v e ( rcvBuf fe r , s izeof ( r cvBu f f e r ) ) ;

Switch SW15/5/6 respective SW15/7/8 must be used to active the ports, asshown in Figure 5.9.

The logic level of the following pins MUST NOT be touched by the pro-grammer when using the UART components:

• RS-232 A: Port E PE0, PE1

41

5 bigAVR6 5.2 Supported Modules

• RS-232 B: Port E PD2, PD3

Additionally, the following restrictions have to be noticed:

• RS-232 Port A: disable Jumper J21(set to on board programmer)

• RS-232 Port B: Port PD3 servers as TX, but also connected to RTC.Disable with switch SW15/1

Figure 5.9: RS-232 Ports, [Mika]

5.2.8 RTC

The DS1307 Real Time Clock provides date and time with granulation of 1second and an configureable square wave output. DS1307C provides interfaceRTC as shown in 5.10 with functions to set the time, start/stop the clock andconfigure the square wave output.

Listing 5.10: RTC.nc/∗∗∗ @author Markus Hartmann e988811@student . tuwien . ac . at∗/

#include ”RTC. h”

i n t e r f a c e RTC{

/∗∗∗ S ta r t s the Realtime Clock∗∗ @param data S t a r t s the Clock , s e t t i n g date / time∗ I f NULL i s passed , the c l o c k i s s t a r t e d wi thout∗ changing anything .∗

42

5 bigAVR6 5.2 Supported Modules

∗ @return SUCCESS i f bus a v a i l a b l e and reque s t accepted .∗/

command e r r o r t s t a r t ( r t c t im e t ∗data ) ;

/∗∗∗ Stops the Realtime Clock − The seconds are s e t to 0∗∗ @return SUCCESS i f bus a v a i l a b l e and reque s t accepted .∗/

command e r r o r t stop ( void ) ;

/∗∗∗ Read time∗∗ @param data A poin t to a data b u f f e r where the r e s u l t s w i l l be s to red∗∗ @return SUCCESS i f bus a v a i l a b l e and reque s t accepted .∗/

command e r r o r t readTime ( r t c t im e t ∗data ) ;

/∗∗∗ No t i f i c a t i o n tha t the r e s u l t s are ready∗∗/

event void timeReady ( void ) ;

/∗∗∗ Control the Squarewave output∗∗ @param squareConf ig Output f requency o f the squarewave generator o f the r t c :∗ RTC SQW OFF, − Disab l e squarewave output∗ RTC SQW 1HZ, − Enables 1Hz squarewave output∗ RTC SQW 4KHZ, − Enables 4kHz output∗ RTC SQW 8KHZ, − Enables 8kHz output∗ RTC SQW 32KHZ − Enables 32kHz output∗∗ @return SUCCESS i f bus a v a i l a b l e and reque s t accepted .∗/

command e r r o r t setSquareWave ( r t c s qw t squareConf ig ) ;}

The DS1307 is controlled via I2C, which is a shared resource in TinyOS. Ifthe I2C Bus is not available, a call to an RTC function will fail and return anerror. A 3V battery enables operation of the real-time clock even if the boardis disconnected from power supply.

The I2C Bus by default uses PortD0 and PortD1, the square wave out-put is on PortD3 and/or PortE6. The I2C Ports are defined in tos/chip-s/atm128/i2c/HplAtm128I2CBusC.nc - as seen in 5.10 it would also be possibleto use E4 and E5, although this is not currently supported by TinyOS.

5.2.9 Printf Library

Although not a hardware module, the Printf Library is highly dependent onthe underlying modules. To use it, one must declare the corresponding stdocomponent in the configuration, include printf.h and - if used for debugging

43

5 bigAVR6 5.3 Supported Microcontrollers

Figure 5.10: DS1307 Ports, [Mika]

- debug.h. No additional wiring is necessary. There are 3 stdo componentsavailable:

• 1. StdoUartCsends output via RS232 port B

• 2. StdoGlcdCshows output on the graphical lcd

• 3. StdoDebugCsends printf and debug output via uart1 in debug modeshows printf on the graphical lcd in normal mode

To enable debug mode without changing code use the following line for com-pilation:

>env ‘ ‘CFLAGS=−DDEBUG’ ’ make bigAVR6 ( i n s t a l l )

5.3 Supported Microcontrollers

Components HplAtm128[0]GeneralIOFastPortC were added to provide inter-face GeneralIOPort for use with both Microcontrollers.

5.3.1 ATmega128

The ATmega128 Microcontroller is supported natively by TinyOS. However,there is one necessary change to operate it with the bigAVR6 platform:

The original implementation was operated with an asynchronus timer sys-tem driven by the clock output of the (ZigBee) wireless transceiver. As the

44

5 bigAVR6 5.3 Supported Microcontrollers

bigAVR6 development board has no external clock to listen to, it had to bechanged to synchroneous operation. The changed/added files can be foundunder (tos/chips ecs/atm128/timerSync). Also it is now required to spec-ify the correct clock frequency “MHZ” with a define in (tos/platforms/bi-gAVR6/hartware.h)

MHZ has to be 8 or 16 - otherwise compilation will fail.

IMPORTANT NOTE:

It is possible to use a wrong value for MHZ - for example 8 when operatingwith 16 MHz. The correctness of this value can not checked and may leadto wrong baudrate calculation, incorrect timer signals and other undefinedbehavior.

5.3.2 ATmega1280

The ATmega1280 is not supported by the original TinyOS, but is largelyidentical with the supported ATmega1281. The same changes regarding asyn-chronus/synchronus operation had to be made as within the ATmega128.

In addition it was necessary to change the HplAtm1280GeneralIOSlowPinPas the ATmega1280 supports more pins and needs 16Bit Addresses to accessits Ports.

45

6 Resources used

• http://www.youtube.com/watch?v=j6hRsue5b30 / lecture about tinyos

• http://www.tinyos.net/tinyos-2.x/doc/html/tep2.html

• http://www.tinyos.net/tinyos-2.x/doc/html/tep106.html

• http://www.tinyos.net/tinyos-2.x/doc/html/tep108.html

• http://www.tinyos.net/tinyos-2.x/doc/html/tep112.html

• http://www.tinyos.net/tinyos-2.x/doc/pdf/tinyos-programming.pdf

46

Bibliography

[Lev] Philip Levis. TinyOS Programming. Treitlstr. 3/3/182-1, 1040 Vienna,Austria. Available at http://www.tinyos.net/tinyos-2.x/doc/pdf/tinyos-programming.pdf.

[LS] Philip Levis and Cory Sharp. Scheduler and Tasks. Treitlstr. 3/3/182-1, 1040 Vienna, Austria. Available at http://www.tinyos.net/

tinyos-2.x/doc/html/tep106.html.

[Mika] MikroElektronika. BIGAVR6 User Manual. MikroElektronika. Avail-able at http://www.mikroe.com/eng/downloads/get/352/bigavr6_

manual_v100.pdf”.

[Mikb] MikroElektronika. MikroElektronika Homepage. MikroElektron-ika. Available at http://www.mikroe.com/eng/products/view/165/

smartmp3-board/”.

[Vie] ECS TU Vienna. Getting Started Guide. ECS TU Vienna. Available athttp://ti.tuwien.ac.at/ecs/teaching/courses/mclu/manuals/

getting-started-guide/at_download/file”.

47

A Setup Guide

It is assumed that avr-gcc and avrprog2 are already installed and working. Thefollowing setup guide is from [Vie]

If not already installed, you have to install git by executing

sudo apt-get install git

Download the according binary packages of the nesC compiler and sometool available from the course homepage http://ti.tuwien.ac.at/ecs/

teaching/courses/mclu/misc/tinyos-packages. For the correct path askyour adviser of the course. If you don’t know if you need the 32 bit or 64 bitpackages find it out by

uname -m

If it says x86 64 you need the amd64 packages, i386 otherwise.

Install the nesC compiler including some tools, execute following lines in yourterminal when running a 32 bit linux:

sudo dpkg -i nesc_1.3.1-20100325_i386.deb

tinyos-tools-ecs_1.4.0-20100326_i386.deb

or in your 64 bit environment:

sudo dpkg -i nesc_1.3.1-20100325_amd64.deb

tinyos-tools-ecs_1.4.0-20100326_amd64.deb

Get TinyOS using

git clone <<insert repository path here>>

Get the repository path from your course advisor.

48

A Setup Guide

Syntax highlighting

Here you can find a TinyOS syntax highlighting file for ”gedit”: http://www.keally.org/2009/02/20/tinyos-and-nesc-syntax-highlighting/

Envoironment variables

Enter in a terminal:

echo "export TOSROOT=/home/user/TOS_ECS" >> ~/.profile

echo "export TOSDIR=\$TOSROOT/tos" >> ~/.profile

echo "export MAKERULES=\$TOSROOT/support/make/Makerules" >> ~/.profile

where /home/user has to be replaced with the correct path.

You can always change your settings by editing your .profile file and reloadit with

. ~/.profile

To compile a TinyOS program for the bigAVR6 1280 platform enter

make bigAVR6_1280

make bigAVR6_1280 install,<TOS_NODE_ID>

where bigAVR6 1280 can be replaced with any supported platform. The idafter install is optional.

A.0.3 Visualize Components

TinyOS has a documentation feature called nesdoc which generates documen-tation automatically. To generate documentation for an application enter

make bigAVR6_1280 docs

You will now find the documentation under $TOSROOT/doc/nesdoc/bi-gAVR6 1280.

To visualize your entire application you can enter

make bigAVR6_1280 appdoc

which will generate a YourAppC.png file in the app directory.

49

B Pin Configuration of bigAVR6

PORTAA0 A1A2 A3 LCD128x64

LCD128x64 A4 A5 LCD128x64LCD128x64 A6 A7 LCD128x64

PORTBDS1820 B0 B1 SPI SCK

SPI MOSI B2 B3 SPI MISOB4 B5B6 B7

PORTCC0 C1

LCD2x16 C2 C3 LCD2x16LCD2x16 C4 C5 LCD2x16LCD2x16 C6 C7 LCD2x16

PORTDRTC EEPROM D0 D1 EEPROM RTC

RS-232B D2 D3 RS-232B RTCD4 D5 CAN

CAN D6 D7

PORTERS-232A E0 E1 RS-232A

LCD128x64 E2 E3 LCD128x64EEPROM RTC LCD128x64 E4 E5 LCD128x64 RTC EEPROM

RTC LCD128x64 E6 E7 LCD128x64

PORTFTouch Panel F0 F1 Touch Panel

F2 F3F4 F5F6 F7

50

B Pin Configuration of bigAVR6

PORTGDS1820 G0 G1 MMC CS

MMC CD G2 G3 Touch PanelTouch Panel G4 G5

G6 G7

51