TinyOS与nesc编程指南

4星 · 超过85%的资源需积分: 9 133 浏览量更新于2024-08-02 收藏 1.15MB PDF 举报

"TinyOS NES(C)编程参考手册" TinyOS是一个专为传感器网络设计的操作系统，而nesc（Network Embedded System Configuration）是一种编程语言，用于构建TinyOS中的组件和接口。这个参考手册由Philip Levis撰写，旨在帮助开发者理解和使用nesc进行有效编程。 1. **链接与命名空间** - 链接过程涉及到将源代码编译成可执行文件的过程，nesc处理C、C++和Java代码的链接。 - 命名空间是nesC的一个关键特性，它允许在不同模块中使用相同的名字而不会产生冲突，通过组件和接口的命名规则来管理这些名字。 2. **接口与模块** - 分阶段接口（Split-Phase Interfaces）：nesC支持异步通信，分阶段接口允许操作的开始和结束分开，这样可以处理并发和延迟。 - 接口带参数：nesC接口可以接受参数，这使得接口更加灵活，可以适应不同的功能需求。 - 模块实现：模块是nesC的基本构造单元，包含接口的实现。 - 任务（Tasks）：nesC中的任务类似于线程，它们代表并发执行的实体。 - 并发控制：nesC提供了一套机制来管理并发任务的执行，确保数据一致性。 3. **配置与连接** - 配置是nesC中的一个关键概念，用于指定系统中组件之间的连接和依赖关系。 - 通过接线（Wiring）定义组件间的交互，有Pass-Through Wiring和Combine Functions等方式。 4. **参数化接线** - 参数化接线允许在配置中使用变量或表达式，增加了灵活性，例如设置默认值。 - unique() 和 uniqueCount() 函数确保每个实例的唯一性，这对于资源有限的传感器网络尤其重要。 5. **泛型组件** - 泛型模块和配置允许创建可复用的代码，适用于多种场景。 - 通过具体的例子如TimerMilliC、AMSenderC、CC2420SpiC和BlockStorageC，手册展示了如何实现和使用这些泛型组件。 6. **设计模式** - 设计模式是解决特定问题的通用解决方案，nesC中也有类似的概念，手册可能涵盖了如何在nesC环境中应用这些模式。这个手册对nesC编程语言和TinyOS操作系统的理解提供了深入的指导，包括从基本概念到高级特性的详细解释，对于想要开发和维护传感器网络软件的工程师来说是一份宝贵的资源。通过学习这个手册，读者能够掌握nesC语言的关键特性，如并发控制、接口设计和组件连接，从而有效地利用TinyOS进行物联网应用的开发。

1.5. WHY? 13

components RoutingLayerC and PacketLayerC are completely decoupled, and are only bound together when wired.

1.5 Why?

Having a global namespace requires C, C++, and Java to reply on dynamic composition. Referencing a function

requires referencing a unique name in the global namespace, so code uses a level of indirection — function pointers

or factories — in order to decouple one implementation from another.

nesC takes a different approach. First, code is broken up into components, discrete units of functionality. A com-

ponent can only reference variables from its own, local namespace. A component can’t name a variable in another

component. However, a component can declare that it uses a function deﬁned by another component. It can also

declare that it provides a function that another component can call. Building a nesC program involves writing com-

ponents and wiring users to providers. Because this composition occurs at compile-time, it doesn’t require runtime

allocation or storing function pointers in RAM. Additionally, since a program does not have these levels of indirection,

the nesC compiler knows the complete call graph. Before wiring, a component could be calling any other component,

and so is completely decoupled from whom it calls. However, in an application, the cal l is wired to a speciﬁc endpoint,

and so the nesC compiler can optimize across the call boundary. In practice, nesC often inlines a call that crosses ﬁve

or six components into a ﬂat instruction stream with no function calls.

TinyOS and nesC can take this approach because, unlike end-user computers, which need to be able to dynamically

load new programs in response to user input, sensor networks are composed of embedded computers, which have well-

deﬁned and tightly speciﬁed uses. While these might evolve over time, this evolution is very slow in comparison to

how often a PC loads new programs. There’s an additional side to embedment which motivates using static, rather

than dynamic approaches. Because traditional computers usually have some sort of user interaction, faults are more

easily detected. If the server is acting funny, you notice, and reboot it. If your word processor is slow, you close it

and reopen it. The same is not true for embedded systems, which operate, for the most part, unattended. For example,

consider traditional computers that have roles resembling embedded systems, such as a dedicated mail server. If a

logging failure causes the mail server to start losing some mail messages, it might — and often does — go unnoticed

for a long time.

At the level of programming actual behavior or algorithms, nesC is usually quite accessible if you know one

of the above languages. It is, after all, a C dialect. A component can only reference functions in its speciﬁcation

and only reference variables declared within it, but this usually isn’t too hard to get a handle on. Understandably,

the part that most people new to the language ﬁnd most challenging is wiring, as there’s no clear analogue in other

system languages. Composing nesC components into working, ﬂexible, and reusable systems requires learning a new

language. While the language itself is very simple (it only really has two operators), the considerations are foreign to

most programmers who are used to global namespaces. Therefore, while this book does go over implementations, it

is mostly dedicated to wiring and composition, as these are what most nesC programmers ﬁnd challenging.

Chapter 2

Interfaces and Modules

nesC has two kinds of components: conﬁgurations and modules. Conﬁgurations, discussed in Section III, are how

components are wired together. Modules, in contrast, are implementations. Conﬁgurations connect the declarations of

different components, while modules deﬁne functions and allocate state.

2.1 Split Phase

Because sensor nodes have a broad range of hardware capabilities, one of the goals of TinyOS is to have a ﬂexible

hardware/software boundary. An application that encrypts packets should be able to interchangeably use hardware or

software implementations. Hardware, however, is almost always split-phase rather than blocking. It is split-phase in

that completion of a request is a callback. For example, to acquire a sensor reading with an analog-to-digital converter

(ADC), software writes to a few conﬁguration registers to start a sample. When the ADC sample completes, the

hardware issues an interrupt, and the software reads the value out of a data register.

Now, let’s say that rather than directly sampling, the sensor implementation actually samples periodically and when

queried gives a cached value. This may be necessary if the sensor needs to continually calibrate itself. Magnetometer

drivers sometimes do this due to the effect of the Earth’s magnetic ﬁeld, as two sensors oriented differently might have

very different magnetometer ﬂoors. Drivers estimate the ﬂoor and essentially return a measure of recent change, rather

than an absolute value. From a querying standpoint, the implementation of the sensor is entirely in software. This fact

should not be apparent to the caller. For ease of composition, sampling a self-calibrating magnetometer should be the

same as a simple photoresistor. But the magnetometer is a synchronous operation (it can return the result immediately)

while the ADC is split-phase.

The basic solution to this problem is to make one of the two look like the other: either give the magnetometer a

split-phase interface, or make the ADC synchronous by blocking. If the ADC interrupt is very fast, the ADC driver

might be able to get away with a simple spin loop to wait until it ﬁres. If the interrupt is slow, then this wastes a lot of

CPU cycles and energy. The traditional solution for this latter case (e.g., in traditional OSes) is to use multiple threads.

16 CHAPTER 2. INTERFACES AND MODULES

When the code requests an ADC sample, the OS sets up the request, puts the calling thread on a wait queue, starts

the operation, and then schedules another thread to run. When the interrupt comes in, the driver resumes the waiting

thread and puts it on the OS ready queue.

The problem with threads in embedded systems is that they require a good deal of RAM. Each thread has its own

private stack which has to be stored when a thread is waiting or idle. E.g., when a thread samples a blocking ADC and

is put on the wait queue, the memory of its entire call stack has to remain untouched so that when it resumes it can

continue execution. RAM is a very tight resource on current sensor node platforms. Early versions of TinyOS ran in

512 bytes of RAM. When a thread is idle, its stack is wasted storage, and allocating the right sized stack for all of the

threads in the system can be a tricky business.

TinyOS therefore takes the opposite approach. Rather than make everything synchronous through threads, opera-

tions that are split-phase in hardware are split-phase in software as well. This means that many common operations,

such as sampling sensors and sending packets, are split-phase. An important characteristic of split-phase interfaces

is that they are bidirectional: there is a downcall to start the operation, and an upcall that signiﬁes the operation is

complete. In nesC, downcalls are generally commands, while upcalls are events. An interface speciﬁes both sides of

this relationship. For example, this is the basic TinyOS packet send interface, Send:

interface Send {

command error_t send(message_t* msg, uint8_t len);

command error_t cancel(message_t* msg);

event void sendDone(message_t* msg, error_t error);

}

Whether a component provides or uses the Send interface deﬁnes which side of the split-phase operation it rep-

resents. A provider of Send deﬁnes the send and cancel functions and can signal the sendDone event. Conversely, a

user of Send needs to deﬁne the sendDone event and can call the send and cancel commands. When a call to send

returns SUCCESS, the msg parameter has been passed to the provider, which will try to send the packet. When the

send completes, the provider signals sendDone, passing the pointer back to the user.

2.2 Interfaces with Arguments

Interfaces can take types as arguments. For example, Read is a simple interface for acquiring sensor readings:

interface Read<val_t> {

command error_t read();

event void readDone(error_t err, val_t t);

}

Type arguments to interfaces are in angle brackets. The Read interface has a single argument, which deﬁnes the

type of the data value that it produces. For example, a magnetometer component that produces a 16-bit reading might

look like this:

剩余76页未读，继续阅读

ussthao

粉丝: 12
资源: 6

TinyOS与nesc编程指南

TinyOS-nesC编程参考手册详解

TinyOS NesC编程参考手册

TinyOS-nesC编程基础与链接模型解析

TinyOS-nesC编程参考手册分享.pdf

tinyos-programming.rar_TinyOS Programmi_tinyos编程_编程手册

nesc手册 tinyos开发语言参考手册

nesc参考手册 zigbex

TinyOS.zip_tinyos

TinyOS与nesC编程详解

nesC1.1语言参考手册 - TinyOS组件编程

最新资源