没有合适的资源?快使用搜索试试~ 我知道了~
nesC Language Reference Manual.
5星 · 超过95%的资源 需积分: 10 9 下载量 143 浏览量
2011-12-19
16:40:52
上传
评论
收藏 211KB PDF 举报
温馨提示
试读
25页
这篇文档对nesc语言介绍很详细,细节说的很多,对于学习tinyos/nesc很有帮助,想下得童鞋不要错过哦
资源推荐
资源详情
资源评论
nesC Language Reference Manual
David Gay, David Culler, Philip Levis
September 2002
1 Introduction
nesC is an extension to C [2] designed to embody the structuring c oncepts and execution model of
TinyOS [1]. TinyOS is an event-driven operating system designed for sensor network nodes that
have very limited resources (e.g., 8K bytes of program memory, 512 bytes of RAM). TinyOS has
been reimpleme nted in nesC.
The basic concepts behind nesC are:
• Separation of construction and composition: programs are built out of components, which are
assembled (“wired”) to form whole programs. Components define two scopes, one for their
specification (containing the names of their interface instances) and one for their implemen-
tation. Components have internal concurrency in the form of tasks. Threads of control may
pass into a component through its interfaces. These threads are rooted either in a task or a
hardware interrupt.
• Specification of component behaviour in terms of set of interfaces. Interfaces may be provided
or used by the component. The provided interfaces are intended to represent the functionality
that the component provides to its user, the used interfaces represent the functionality the
component needs to perform its job.
• Interfaces are bidirectional: they specify a set of functions to be implemented by the inter-
face’s provider (commands) and a set to b e implemented by the interface’s user (events).
This allows a s ingle interface to represent a com plex interaction between components (e.g.,
registration of interest in some event, followed by a callback when that event happens). This
is critical because all lengthy commands in TinyOS (e.g. send packet) are non-blocking; their
completion is signaled through an event (send done). By specifying interfaces, a component
cannot call the send command unless it provides an implementation of the sendDone event.
Typically commands call downwards, i.e., from application components to those closer to
the hardware, while events call upwards. Certain primitive events are bound to hardware
interrupts (the nature of this binding is system-dependent, so is not described further in this
reference manual).
• Components are statically linked to each other via their interfaces. This increases runtime
efficiency, encourages rubust design, and allows for better static analysis of program’s.
• nesC is designed under the expectation that code will be generated by whole-program com-
pilers. This should also allow for better code generation and analysis.
1
This document is a reference manual for nesC rather than a tutorial. The TinyOS tutorial
1
presents
a gentler introduction to nesC.
The rest of this document is structured as follows: Section 2 presents the notation used in the
reference manual. Sections 3, 4, 5, and 6 present nesC interfaces and components. Section 7 explains
how C files, nesC interfaces and components are assembled into an application. Section 8 covers the
remaining miscellaneous features of nesC. Finally, Appendix A fully defines nesC’s grammar (as an
extension to the C grammar from Appendix A of Kernighan and Ritchie (K&R) [2, pp234–239]),
and Appendix B is a glossary of the terms used in this reference manual.
2 Notation
The typewriter font is used for nesC code and for filenames. Single symbols in italics, with
optional subscripts, are used to refer to nesC entities, e.g., “component K” or “value v”.
The grammar of nesC is an extension the ANSI C grammar. We chose to base our presentation
on the ANSI C grammar from Appendix A of Kernighan and Ritchie (K&R) [2, pp234–239]. We
will not repeat productions from that grammar here. Words in italics are non-terminals and non-
literal terminals, typewriter words and symbols are literal terminals. The subscript opt indicates
optional terminals or non-terminals. In some cases, we change some ANSI C grammar rules. We
indicate this as follows: also indicates additional pro ductions for existing non-terminals, replaced
by indicates replacement of an existing non-terminal.
Explanations of nesC constructs are presented along with the corresponding grammar fragments.
In these fragments, we sometimes use . . . to represent elided productions (irrelevant to the construct
at hand). Appendix A presents the full nesC grammar.
Several examples use the uint8 t and uint16 t types from the C99 standard inttypes.h file.
3 Interfaces
Interfaces in nesC are bidirectional: they specify a multi-function interaction channel between two
components, the provider and the user. The interface specifies a set of named functions, called
commands, to be implemented by the interface’s provider and a set of named functions, called
events, to be implemented by the interface’s user.
This section explains how interfaces are specified, Section 4 explains how components specify the
interfaces they provide and use, Section 5 explains how commands and events are called from and
implemented in C code and Section 6 explains how component interfaces are linked together.
Interfaces are specified by interface types, as follows:
nesC-file:
includes-list
opt
interface
. . .
interface:
interface identifier { declaration-list }
1
Available with the TinyOS distribution at http://webs.cs.berkeley.edu
2
storage-class-specifier: also one of
command event
This declares interface type identifier. This identifier has global scope and belongs to a separate
namespace, the component and interface type namespace. So all interface types have names distinct
from each other and from all components, but there can be no conflicts with regular C declarations.
Each interface type has a separate scope for the declarations in declaration-list. This declaration-list
must consist of function declarations with the command or event storage class (if not, a compile-time
error occurs).
An interface can optionally include C files via the includes-list (see Section 7).
A simple interface is:
interface SendMsg {
command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg);
event result_t sendDone(TOS_MsgPtr msg, result_t success);
}
Provides of the SendMsg interface type must implement the send command, while users must
implement the sendDone event.
4 Component Specification
A nesC component is either a module (Section 5) or a configuration (Section 6):
nesC-file:
includes-list
opt
module
includes-list
opt
configuration
. . .
module:
module identifier specification module-implementation
configuration:
configuration identifier specification configuration-implementation
Component’s names are specified by the identifier. This identifier has global scope and belongs to
the component and interface type namespace. A component introduces two per-component scopes:
a specification scope, nested in the C global scope, and an implementation scope nested in the
specification sc ope.
A component can optionally include C files via the includes-list (se e Section 7).
The specification lists the specification elements (interface instances, commands or events) used or
provided by this component. As we saw in Section 3, a component must implement the commands
3
of its provided interfaces and the events of its used interfaces. Additionally, it must implement its
provided commands and events.
Typically, commands “call down” towards the hardware components and events “call up” towards
application components (this assumes a view of nesC applications as a graph of components with
application components on top). A thread of control crosses components only though its specifica-
tion elements.
Each specification element has a name (interface instance name, command name or event name ).
These names belong to the variable name space of the per-component-specification scope.
specification:
{ uses-provides-list }
uses-provides-list:
uses-provides
uses-provides-list uses-provides
uses-provides:
uses specification-element-list
provides specification-element-list
specification-element-list:
specification-element
{ specification-elements }
specification-elements:
specification-element
specification-elements specification-element
There can be multiple uses and provides directives in a component specification. Multiple used
or provided specification elements can be grouped in a single directive by surrounding them with
{ and }. For instance, these two specifications are identical:
module A1 { module A1 {
uses interface X; uses {
uses interface Y; interface X;
} ... interface Y;
}
} ...
An interface instance is specified as follows:
specification-element:
interface renamed-identifier parameters
opt
. . .
renamed-identifier:
identifier
4
identifier as identifier
interface-parameters:
[ parameter-type-list ]
The complete syntax for interface instance declaration is interface X as Y, explicitly specifying
Y as the instance’s name. The interface X syntax is a shorthand for interface X as X.
If the interface-parameters are omitted, then interface X as Y declares a simple interface in-
stance, corresponding to a single interface to this component. If the interface-parameters are
present (e.g., interface SendMsg S[uint8 t id]) then this is a declaration of a parameterised
interface instance, corresponding to multiple interfaces to this component, one for each distinct
tuple of parameter values (so interface SendMsg S[uint8 t id] declares 256 interfaces of type
SendMsg). The types of the parameters must be integral types (enums are not allowed at this time).
Commands or events can b e included directly as specification elements by including a standard C
function declaration with command or event as its storage class specifier:
specification-element:
declaration
. . .
storage-class-specifier: also one of
command event
It is a compile-time error if the declaration is not a function declaration with the command or event
storage class.
As with interface instances, commands (events) are simple commands (simple events) if no interface
parameters are specified, or parameterised commands (parameterised events) if interface parameters
are specified. The interface-parameters are placed before the function’s regular parameter list, e.g.,
command void send[uint8 t id](int x):
direct-declarator: also
direct-declarator interface-parameters ( parameter-type-list )
. . .
Note that interface parameters are only allowed on commands or events within component specifi-
cations, not within interface types.
Here is a full specification example:
configuration GenericComm {
provides {
interface StdControl as Control;
interface SendVarLenPacket;
// The interface are parameterised by the active message id
interface SendMsg[uint8_t id];
interface ReceiveMsg[uint8_t id];
5
剩余24页未读,继续阅读
资源评论
- 孔雀東南飞2012-11-26最近在弄有关WSN的变成,所以打算深入学习NESC语言,感谢LZ
yanghaojy32
- 粉丝: 3
- 资源: 13
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功