Go to download page of the Graphviz project +and download the appropriate RPM. You only need the basic graphviz RPM (graphviz-); +you don't need all of the add-ons, such as -devel, -doc, -perl, etc. +If you're not sure what version of Linux you're running,

might give you some useful information. Install the rpm with rpm -i rpm-name. +In the case of Windows, there is a simple install program, so you don't need to deal with RPMs.

Pins and Buses

Low-Level I/O

@@ -300,12 +300,12 @@ ul.auto-toc { - + - + - + @@ -321,35 +321,34 @@ TEP 1.

Abstract

The memo documents the TinyOS 2.x interfaces used for controlling -digital IO functionality and digital interfaces other than serial -communication covered in [tep113].

+digital IO functionality and digital interfaces.

1. Introduction

The canonical TinyOS device is likely to have a variety of digital interfaces. These interfaces may be divided into two broad -categories. The first are general purpose digital I/O lines (pins) -for individual digital signals at physical pins on a chip or -platform. The second are digital I/O interfaces that have predefined -communication protocol formats. The two buses covered in this -document are the Serial Peripheral Interface (SPI) and the -Inter-Integrated Circuit (I2c) or Two-Wire interface. While there are -likely other bus formats, we presume SPI and I2C to have the largest -coverage. While the UART interface is also in this category, it is -covered separately in [tep113].

This memo documents the interfaces used for pins and the two buses.

+categories. The first are general purpose digital I/O lines (pins) for +individual digital signals at physical pins on a chip or platform. The +second are digital I/O interfaces that have predefined communication +protocol formats. The three buses covered in this document are the +Serial Peripheral Interface (SPI), the Inter-Integrated Circuit (I2C) +or Two-Wire interface, and the Universal Asynchronous +Receiver/Transmitter (UART) interface. While there are likely other +bus formats, we presume SPI, I2C, and UART to have the largest +coverage.

This memo documents the interfaces used for pins and the three buses.

2. Pins

General Purpose I/O (GPIO) pins are single, versatile digital I/O signals -individually controllable on a particular chip or platform. Each GPIO -can be placed into either an input mode or an output mode. On -some platforms a third 'tri-state' mode may exist, but this -functionality is platform specific and will not be covered in this -document.

On many platforms, a physical pin may function as either a digital GPIO -or another special function I/O such. Examples include ADC I/O or a bus -I/O. Interfaces to configure the specific function of a pin are +

General Purpose I/O (GPIO) pins are single, versatile digital I/O +signals individually controllable on a particular chip or +platform. Each GPIO can be placed into either an input mode or an +output mode. On some platforms a third 'tri-state' mode may exist, but +this functionality is platform specific and will not be covered in +this document.

On many platforms, a physical pin may function as either a digital +GPIO or another special function I/O such. Examples include ADC I/O or +a bus I/O. Interfaces to configure the specific function of a pin are platform specific.

The objective of the interfaces described here is not to attempt to cover all possibilities of GPIO functionality and features, but to @@ -398,7 +397,9 @@ interface GeneralIO async command void toggle(); async command bool get(); async command void makeInput(); + async command bool isInput(); async command void makeOutput(); + async command bool isOutput(); }

@@ -414,7 +415,9 @@ through a platform specific HAL interface.

interface GpioInterrupt { async command error_t enableRisingEdge(); + async command bool isRisingEdgeEnabled(); async command error_t enableFallingEdge(); + async command bool isFallingEdgeEnabled(); async command error_t disable(); async event void fired(); @@ -428,12 +431,15 @@ with a GPIO event. Platforms MAY provide this interface.

Some platforms may have hardware support for such a feature. Other platforms may emulate this capability using the SoftCaptureC component. The interface makes not declaration of the precision or -accuracy of the timestamp with respect to the associated GPIO event.

+accuracy of the timestamp with respect to the associated GPIO +event.

 interface GpioCapture {
 
   async command error_t captureRisingEdge();
+  async command bool isRisingEdgeEnabled();
   async command error_t captureFallingEdge();
+  async command bool isFallingEdgeEnabled();
   async event void captured(uint16_t time);
   async command void disable();
 
@@ -463,18 +469,18 @@ interfaces and implementations.
 asynchronous packet level interface. The byte level interface is
 intended for short transactions (3-4 bytes) on the SPI bus.
 -interface SPIByte {
-  async command error_t write( uint8_t tx, uint8_t* rx );
+interface SpiByte {
+  async command uint8_t write( uint8_t tx );
 }
 
 The packet level interface is for larger bus transactions. The
-pointer/length interface permits use of hardware assist such as DMA.
+pointer/length interface permits use of hardware assist such as
+DMA.
 -interface SPIPacket {
-
+interface SpiPacket {
   async command error_t send( uint8_t* txBuf, uint8_t* rxBuf, uint16_t len );
   async event void sendDone( uint8_t* txBuf, uint8_t* rxBuf, uint16_t len,
-                            error_t error );
+                             error_t error );
 }
 
 
@@ -483,33 +489,112 @@ interface SPIPacket {
 The Inter-Integrated Circuit (I2C) interface is another type of
 digital bus that is often used for chip-to-chip communication. It is
 also known as a two-wire interface.
-The I2CPacket interface provides for asynchronous Master mode communication on an
-I2C with application framed packets.  It supports only single
-transfers with a start-stop condition around each transfer.
+The I2CPacket interface provides for asynchronous Master mode
+communication on an I2C with application framed packets. Individual
+I2C START-STOP events are controllable which allows the using
+component to do multiple calls within a single I2C transaction and
+permits multiple START sequences
 Platforms providing I2C capability MUST provide this interface.
 -interface I2CPacket {
-  async command result_t readPacket(uint16_t _addr, uint8_t _length, uint8_t* _data);
-  async command result_t writePacket(uint16_t _addr, uint8_t _length, uint8_t* _data);
-  async event void readPacketDone(uint16_t addr, uint8_t length, uint8_t* data, result_t success);
-  async event void writePacketDone(uint16_t addr, uint8_t length, uint8_t* data, result_t success);
+interface I2CPacket<addr_size> {
+  async command error_t read(i2c_flags_t flags, uint16_t addr, uint8_t length, u int8_t* data);
+  async event void readDone(error_t error, uint16_t addr, uint8_t length, uint8_t* data);
+  async command error_t write(i2c_flags_t flags, uint16_t addr, uint8_t length, uint8_t* data);
+  async event void writeDone(error_t error, uint16_t addr, uint8_t length, uint8_t* data)
+}
+
+The interface is typed according to the addressing space the
+underlying implementation supports.  Valid type values are below.
++TI2CExtdAddr - Interfaces uses the extended (10-bit) addressing mode.
+TI2CBasicAddr - Interfaces uses the basic (7-bit) addressing mode.
+
+The i2c_flags_t values are defined below. The flags define the
+behavior of the operation for the call being made. These values may be
+ORed together.
++I2C_START    - Transmit an I2C STOP at the beginning of the operation.
+I2C_STOP     - Transmit an I2C STOP at the end of the operation. Cannot be used
+               with the I2C_ACK_END flag.
+I2C_ACK_END  - ACK the last byte sent from the buffer. This flags is only valid
+               a write operation. Cannot be used with the I2C_STOP flag.
+
+
+
+3.3 UART
+The Universal Asynchronous Receiver/Transmitter (UART) interface is a
+type of serial interconnect. The interface is "asynchronous" since it
+recovers timing from the data stream itself, rather than a separate
+control stream. The interface is split into an asynchronous multi-byte
+level interface and a synchronous single-byte level interface.
+The multi-byte level interface, UartStream, provides a split-phase
+interface for sending and receiving one or more bytes at a time. When
+receiving bytes, a byte-level interrupt can be enabled or an interrupt
+can be generated after receiving one or more bytes. The latter is
+intended to support use cases where the number of bytes to receive is
+already known. If the byte-level receive interrupt is enabled, the
+receive command MUST return FAIL. If a multi-byte receive interrupt is
+enabled, the enableReceiveInterrupt command MUST return FAIL.
++interface UartStream {
+  async command error_t send( uint8_t* buf, uint16_t len );
+  async event void sendDone( uint8_t* buf, uint16_t len, error_t error );
+
+  async command error_t enableReceiveInterrupt();
+  async command error_t disableReceiveInterrupt();
+  async event void receivedByte( uint8_t byte );
+
+  async command error_t receive( uint8_t* buf, uint8_t len );
+  async event void receiveDone( uint8_t* buf, uint16_t len, error_t error );
+}
+
+The single-byte level interface, UartByte, provides a synchronous
+interface for sending and receiving a single byte. This interface is
+intended to support use cases with short transactions. Because UART is
+asynchronous, the receive command takes a timeout which represents
+units in byte-times, after which the command returns with an
+error. Note that use of this interface is discouraged if the UART baud
+rate is low.
++interface UartByte {
+  async command error_t send( uint8_t byte );
+  async command error_t receive( uint8_t* byte, uint8_t timeout );
 }
 
 
 
 
-4. Author's Address
+4. Implementation
+Example implementations of the pin interfaces can be found in tos/chips/msp430/pins,
+tos/chips/atm128/pins, and tos/chips/pxa27x/gpio.
+Example implementations of the SPI interfaces can be found in tos/chips/msp430/usart,
+tos/chips/atm128/spi, and tos/chips/pxa27x/ssp.
+Example implementations of the I2C interfaces can be found in tos/chips/msp430/usart,
+tos/chips/atm128/i2c, and tos/chips/pxa27x/i2c.
+Example implementations of the UART interfaces can be found in tos/chips/msp430/usart,
+tos/chips/atm128/uart/ and tos/chips/pxa27x/uart.
+
+
+5. Author's Address
 
 Phil Buonadonna
-Arched Rock Corporation
+Arch Rock Corporation
 657 Mission St. Ste 600
 San Francisco, CA 94105-4120
 

 phone - +1 415 692-0828 x2833
+

+

+Jonathan Hui
+Arched Rock Corporation
+657 Mission St. Ste 600
+San Francisco, CA 94105-4120
+

+phone - +1 415 692-0828 x2835
 
 
 
-5. Citations
+6. Citations

TinyOS-Version:	2.x
Author:	Phil Buonadonna
Phil Buonadonna, Jonathan Hui
Draft-Created:	23-Jan-2006
Draft-Version:	1.2
Draft-Version:	1.1.2.9
Draft-Modified:	2006-07-12
Draft-Modified:	2006-09-30
Draft-Discuss:	TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu>

diff --git a/doc/html/tep118.html b/doc/html/tep118.html index 47d1b974..dfede355 100644 --- a/doc/html/tep118.html +++ b/doc/html/tep118.html @@ -303,9 +303,9 @@ ul.auto-toc { - + - + @@ -401,7 +401,7 @@ generic configuration DisseminatorC(typedef t, uint16_t key) { provides interface DisseminationUpdate <t>; } -

The t argument MUST be able to fit in a single message_t[tep111_] after +

The t argument MUST be able to fit in a single message_t[1] after considering the headers that the dissemination protocol introduces. A dissemination implementation SHOULD have a compile error if a larger type than this is used.

@@ -516,12 +516,6 @@ trickle.

Philip Levis and Gilman Tolle
Draft-Created:	10-Dec-2004
Draft-Version:	1.2
Draft-Version:	1.1.2.3
Draft-Modified:	2006-07-12
Draft-Modified:	2006-06-20
Draft-Discuss:	TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu>

Docutils System Messages

System Message: ERROR/3 (txt/tep118.txt, line 116); backlink

-Unknown target name: "tep111".

LinkEstimatorP estimates the quality of link to or from each neighbor. Link estimation can be done in a variety of ways, and we do not impose one here. It is decoupled from the establishment of -routes. There is a narrow interface (LinkEstimator) between the link -estimator and the routing engine. The one requirement is that the -quality returned is standardized. A larger return value from -LinkEstimator.getQuality(), LinkEstimator.getforwardQuality(), -LinkEstimator.getreserveQuality() MUST imply that the link to the -neighbor is estimated to be of a higher quality than the one that -results in a smaller return value. The range of value SHOULD be -[0,255] and the variation in link quality in that range SHOULD be -linear. Radio provided values such as LQI or RSI, beacon based link -estimation to compute ETX, or their combination are some possible -approaches to estimating link qualities. LinkEstimatorP MAY have its -own control messages to compute bi-directional link qualities:

9. Funding

As with the IETF, individuals are responsible for their own costs, -which primarily involve meetings, travel, and generation of work -products. Membership participation will involve attendance at -Alliance meetings. Registration fees will be charged to cover costs -associated with adminstration of the meetings.

Companies and institutions are encouraged to contribute financial and -in-kind support. It will be essential that companies provide initial -funding to create the legal structure and to establish basic IT -capabilities to host the web site and working groups.

Initially, we expect that there are no full time employees in the Alliance and that funding needs are limited to such items as lawyer's fees, web site costs, and insurance. If the Alliance eventually requires full time support personnel, the funding structure will have to be re-visited.

As with the IETF, individuals are responsible for their own costs, +which primarily involve meetings, travel, and generation of work +products. The Alliance is predominantly a volunteer organization. +Membership participation will involve attendance at +Alliance meetings. Registration fees will be charged to cover costs +associated with adminstration of the meetings.

To maintain the focus on technical excellence and meritocracy, we want to avoid the heavy-handed quid-pro-quo seen in many industrial consortiums where funding determines influence. The best use of funds and the best form of influence is direct contribution to the work -products of the Alliance. We will permit targeted contributions -toward specific working groups or technical capabilities.

We seek to keep overall structure lean, mostly volunteer. -Focus on desired impact and recognition, rather than control.

Institutional members +products of the Alliance. +To keep the structure of the Alliance and its operations minimalist +and lean, membership focuses on desired impact and recognition, rather +than control. We want the best way to influence the direction of the Alliance +to be to contribute technical work and demonstrate leadership, rather than +try to control what individuals can or cannot contribute.

Companies and institutions are encouraged to contribute financial and +in-kind support. It will be essential that companies provide initial +funding to create the legal structure and to establish basic IT +capabilities to host the web site and working groups. +Institutional members will pay an annual membership fee. In some cases, a contributing corporate member may provide in-kind services such as lawyers' time used to @@ -790,52 +793,80 @@ solicited and encouraged. In this case the donator need not become a contributing corporate member, e.g., in those cases where such a membership may be prohibited or unwanted. The costs of meetings, such as the TinyOS -technology exchange, will be covered through registration fees.

Individuals are responsible -for their own costs such as -for travel, meeting costs, or costs for contributing -software or documentation to the Alliance. The Alliance -is primarily a volunteer organization.

+technology exchange, will be covered through registration fees and +not by institutional membership fees.

Together, the origin, seqno and collect_id fields denote a unique @@ -434,9 +434,9 @@ THL denote a unique *packet instance* within the network. The distinction is important for duplicate suppression in the presence of routing loops. If a node suppresses origin packets, then if asked to forward the same packet twice due to a routing loop, it will -drop the packet. However, if it suppresses packet instances, then -unless the THL has wrapped around to the identical value it had -on previous times around.

A node MUST send CTP data frames as unicast messages with link-layer acknowledgments enabled.

6. Implementation

An implementation of CTP can be found in the tos/lib/net/ctp directory +of TinyOS 2.0. This section describes the structure of that implementation +and is not in any way part of the specification of CTP.

This implementation has three major subcomponents:

1) A link estimator, which is responsible for estimating the +single-hop ETX of communication with single-hop neighbors.

2) A routing engine, which uses link estimates as well as +network-level information to decide which neighbor is the next +routing hop.

3) A forwarding engine, which maintains a queue of packets +to send. It decides when and if to send them. The name is a little +misleading: the forwarding engine is responsible for forwarded traffic +as well as traffic generated on the node.

6.1 Link Estimation

The link estimator estimates the ETX to single-hop neighbors. +The implementation uses two mechanisms to estimate the quality of a link: +periodic broadcast packets and data packets. The estimator itself +only generates broadcast packets. For data traffic, it depends on +other components telling it about acknowledged and unacknowledged +transmissions.

The periodic broadcast packets have sequence numbers, which the +estimator uses to estimate the sender-to-receiver packet reception +rate (PRR). The data payload of periodic broadcast packets contain +these estimates. Therefore, when node A receives a link estimation +broadcast message from node B, it can use the packet header to +estimate the B-to-A PRR and the packet payload to update B's +estimate of the A-to-B PRR.

Multiplying these two values gives a bidirectional PRR, or +an estimate of the probability that if A transmits a packet to B, +B will successfully hear and acknowledge the packet and A will +hear the acknowledgment. The inverse of the bidirecitonal PRR +is the ETX.

CTP link estimation adapts its beaconing rate to be slow when +its routing table is stable and faster when changes occur. +It adjusts the beaconing interval using an algorithm similar +to the trickle dissemination protocol[2_]. CTP sends beacons +more often when one of three conditions occurs:

+
+
The routing table is empty (this also sets the P bit)
+
The node's routing ETX increases by >= 1 trasmission
+
The node hears a packet with the P bit set
+
+

CTP also estimates link quality using data transmissions. This +is a direct measure of ETX. Whenever the data path transmits a +packet, it tells the link estimator the destimation and whether +it was successfully acknowledged. The estimator produces an ETX +estimate every 5 such transmissions, where 0 successes has an +ETX of 6.

The estimator combines the beacon and data estimates by incorporating +them into an exponentially weighted moving average. Beacon-based +estimates seed the neighbor table. The expectation is that the low +beacon rate in a stable network means that for a selected route, +data estimates will outweigh beacon estimates. Additionally, as +the rate at which CTP collects data estimates is proportional to +the transmission rate, then it can quickly detect a broken link and +switch to another candidate neighbor.

6.2 Routing Engine

The

This document describes how to upgrade your TinyOS 1.x environment to a TinyOS 2.x environment. This requires that you not only install the TinyOS 2.x rpm, but also that you upgrade your tools from the toolset @@ -37,9 +32,7 @@ There are 3 steps to upgrading from 1.x to 2.x:

Switching between the two should require switching only these environment +variables.

TinyOS 2.0 has a few tutorials to get a new user started with programming the system. These tutorials introduce nesC programming and some major TinyOS abstractions, such as timers and communication.

Additionally, for more advanced programming, there is a + TinyOS Programming Manual. + The book describes nesC's features in greater detail, + including generic components, concurrency, and common + component design patterns.

In addition to TEPs, which document the organization and design - behind important parts of TinyOS, there is also source code - documentation. TinyOS (nesC) code has nesdoc annotations, - which can be found here (note that this link is external):

- - -

There is similar javadoc documentation for the Java toolchain, - which can be found here:

- - -

There is similar + javadoc documentation for the Java toolchain, + which describes the Java classes and their functionality. This documentation + is incomplete.

Tool	Windows/Cygwin	Linux
avr-binutils†	avr-binutils-2.15tinyos-3.cygwin.i386.rpm	avr-binutils-2.15tinyos-3.i386.rpm
avr-gcc	avr-gcc-3.4.3-1.cygwin.i386.rpm	avr-gcc-3.4.3-1.i386.rpm
avr-libc	avr-libc-1.2.3-1.cygwin.i386.rpm	avr-libc-1.2.3-1.i386.rpm
avarice	avarice-2.4-1.cygwin.i386.rpm	avarice-2.4-1.i386.rpm
insight (avr-gdb)	avr-insight-6.3-1.cygwin.i386.rpm	avr-insight-6.3-1.i386.rpm

Tool	Windows/Cygwin	Linux
base	msp430tools-base-0.1-20050607.cygwin.i386.rpm	msp430tools-base-0.1-20050607.i386.rpm
python tools	msp430tools-python-tools-1.0-1.cygwin.noarch.rpm	msp430tools-python-tools-1.0-1.noarch.rpm
binutils	msp430tools-binutils-2.16-20050607.cygwin.i386.rpm	msp430tools-binutils-2.16-20050607.i386.rpm
gcc	msp430tools-gcc-3.2.3-20050607.cygwin.i386.rpm	msp430tools-gcc-3.2.3-20050607.i386.rpm
libc	msp430tools-libc-20050308cvs-20050608.cygwin.i386.rpm	msp430tools-libc-20050308cvs-20050608.i386.rpm
jtag	Not yet available	msp430tools-jtag-lib-20031101cvs-20050610.i386.rpm
gdb	Not yet available	msp430tools-gdb-6.0-20050609.i386.rpm

Tool	Recommended Windows/Cygwin	Other Windows/Cygwin	Linux	Command
NesC	nesc-1.2.7b-1.cygwin.i386.rpm	nesc-1.2.7a-1.cygwin.i386.rpm	nesc-1.2.7a-1.i386.rpm	`rpm -Uvh`
tinyos-tools	tinyos-tools-1.2.2-1.cygwin.i386.rpm	tinyos-tools-1.2.2-1.cygwin.i386.rpm	tinyos-tools-1.2.2-1.i386.rpm	`rpm -ivh --force` (1.x tree) `rpm -Uvh` (no 1.x tree)

	Windows/Cygwin	Linux
TinyOS	tinyos-2.0.0beta2-3.cygwin.noarch.rpm	tinyos-2.0.0beta2-3.noarch.rpm

Environment Variable	Windows	Linux
TOSROOT	/opt/tinyos-2.x	same as in Cygwin	- -
TOSDIR	$TOSROOT/tos	same as in Cygwin	- -
CLASSPATH	C:\tinyos\cygwin\opt\tinyos-2.x\support\sdk\java\tinyos.jar;.	$TOSROOT/support/sdk/java/tinyos.jar:.	- -
MAKERULES	$TOSROOT/support/make/Makerules	same as in Cygwin	- -
PATH†	/opt/msp430/bin:$PATH	same as in Cygwin	- -

Step 1: Install Java 1.5 JDK

Step 2: Install Cygwin

Step 3: Install native compilers

Step 4: Install TinyOS toolchain

Step 5: Install the TinyOS 2.x source tree

Step 6: Installing Graphviz

Step 1: Install Java 1.5 JDK

Step 2: Install Cygwin

Step 3: Install native compilers

Step 4: Install TinyOS toolchain

Step 5: Install the TinyOS 2.x source tree

Step 6: Installing Graphviz

Pins and Buses

Low-Level I/O

Abstract

1. Introduction

2. Pins

3.3 UART

4. Author's Address

4. Implementation

5. Author's Address

5. Citations

6. Citations

Docutils System Messages

9. Funding

10. Work Products

11. Conclusions

12. Author's Address

6. Implementation

6.1 Link Estimation

6.2 Routing Engine

Docutils System Messages

1. Upgrade your external tools.

Step 1: Upgrade your external tools.

2. Upgrade your TInyOS-specific tools.

Step 2: Upgrade your TinyOS-specific tools.

3. Install the TinyOS 2.x source tree.

Step 3: Install the TinyOS 2.x source tree.

Switching back to a TinyOS 1.x tree

Switching back to a TinyOS 1.x tree