TinyOS与nesC编程指南 - CSDN文库

entrance-tip

已收录资源合集

需积分: 9 27 浏览量更新于2024-07-26 收藏 760KB PDF 举报

"TinyOS编程指南" TinyOS是一个专门为无线传感器网络（Wireless Sensor Networks, WSN）设计的操作系统。它采用了一种名为nesC的编程语言，使得开发者能够有效地编写低功耗、低资源消耗的程序。这本书主要针对nesC语言和TinyOS编程进行深入介绍，旨在帮助读者掌握在TinyOS环境下进行软件开发的基本技能。书中涵盖了许多关键主题，首先，作者Philip Levis在前言中可能会阐述编写此书的目的和nesC语言的重要性，以及对于WSN开发者的价值。他可能还会提到书中内容适合的读者群体，包括初学者和有经验的程序员。在"Programming Hints, Condensed"章节，作者可能提供了一些编程提示和技巧，帮助读者快速上手nesC编程，包括代码组织、效率优化等方面。 "Linking and Namespaces"章节则深入探讨了nesC中的链接机制和命名空间。nesC结合了C、C++和Java的一些特性，因此分别介绍了这三种语言在nesC中的处理方式。同时，该章节会讲解组件（components）和接口（interfaces）的概念，这是nesC中实现模块化和抽象的关键。 "Interfaces and Modules"章节进一步讨论了接口和模块的使用。其中"Split Phase"是指nesC中的一种并发模型，它允许异步通信。"Interfaces with Arguments"解释了如何在接口中传递参数。"Module Implementation"描述了如何实现模块功能，而"Tasks"则涉及任务调度和并发控制。"Concurrency"部分可能涵盖了nesC中处理并发问题的方法，如事件驱动编程。"Allocation"则讨论了内存分配策略。 "Confiurations and Wiring"章节涉及TinyOS配置和组件连接。"The as keyword and other namespace tricks"介绍了如何使用关键字as进行类型转换和命名空间管理。"Pass Through Wiring"和"Combine Functions"讲解了如何将组件连接起来，形成网络中的数据流。"Parameterized Wiring"允许根据需要自定义组件的配置，而"Defaults"和"unique() and uniqueCount()"则提供了关于默认值和唯一性的指导。 "Generic Components"章节引入了泛型组件的概念，使得代码更具有通用性。"Generic Modules"展示了如何创建可复用的模块，"HilTimerMilliC: An Example Use of Generic Components"通过一个实例演示了如何使用泛型组件。"Generic Configurations"则讲述了如何配置这些泛型组件，而"Examples"部分通过"TimerMilliC"和"AMSenderC"等实例进一步巩固了学习。这本书的内容全面且深入，对于想要在TinyOS上进行WSN开发的工程师来说是一份宝贵的参考资料。通过学习，读者可以掌握nesC编程语言和TinyOS操作系统的精髓，从而高效地开发出适应无线传感器网络需求的应用程序。

16 CHAPTER 2. PROGRAMMING HINTS, CONDENSED

intended to be an internal and private part of a larger abstraction, its name should end with P. Never wire to

P components from outside your package (directory).

Programming Hint 10: Use the as keyword liberally.

Programming Hint 11: Never ignore combine warnings.

Programming Hint 12: If a function has an argument which is one of a small number of constants, consider

deﬁning it as a few separate functions to prevent bugs. If the functions of an interface all have an argument

that’s almost always a constant within a large range, consider using a parameterized interface to save code

space. If the functions of an interface all have an argument that’s a constant within a large range but only

certain valid values, implement it as a parameterized interface but expose it as individual interfaces, to both

minimize code size and prevent bugs.

Programming Hint 13: If a component depends on unique, then #deﬁne a string to use in a header ﬁle, to

prevent bugs from string typos.

Programming Hint 14: Never, ever use the “packed” attribute.

Programming Hint 15: Always use platform independent types when deﬁning message formats.

Programming Hint 16: If you have to perform signiﬁcant computation on a platform independent type or

access it many (hundreds or more) times, then temporarily copying it to a native type can be a good idea.

3.1. C 19

var = randVal;

}

}

int bar() { // Scope D

int test;

return 4;

}

int snark() { // Scope E

int var;

return 5;

}

Listing 3.4: Naming scopes in C

In this example, the code in scope C can reference randVal, test, and var, while the code in scope B can

only reference test and var. While both scope B and scope D introduce the same name, test, they do not

conﬂict. Scope E, however, introduces a variable with the name var, which conﬂicts with the var in global

scope. This is commonly called shadowing and while legal, usually causes a compiler to issue a warning.

There is one additional level of scope, provided by the static keyword: ﬁle scope. A variable with the

static keyword can be referenced by code in the same ﬁle, but does not enter the global scope.

Header ﬁles are not a special C construct: they are just a kind of C source ﬁle whose use has evolved

from programming practice. Speciﬁcally, C header ﬁles generally contain only variable declarations. These

declarations match the deﬁnitions of the corresponding implementation ﬁle or object ﬁle.

When a C program is broken up into many ﬁles, those ﬁles can only reference each other through dec-

larations introduced into global scope. If an object ﬁle references but does not deﬁne a variable (a symbol),

then in the linking stage it has to be linked with another object ﬁle that deﬁnes it. This can be a library or

a standard object ﬁle. Because a declaration can only have one deﬁnition, this means that when code ref-

erences a function, for example, it references an implementation. Two source ﬁles that reference the same

function name reference the same function, introducing an unforeseen dependency between the two codes,

because if you want to change the implementation that one uses, you have to change the implementation the

other uses as well.

Function pointers are the common approach to avoid this undesirable binding. Rather than reference a

speciﬁc function, a code can reference a variable that stores a pointer to any function. This allows the code

to resolve the binding at runtime, by choosing what pointer to store in that variable. Using function pointers

allows C software to call new extensions that it could not name when it was compiled, which is critical for

any system with callbacks.

For example, C GUI toolkits need to be able to call functions in response to user events. The function

with the behavior is part of the application code, but the pre-compiled GUI toolkit needs to be able to call

20 CHAPTER 3. LINKING AND NAMESPACES

it. So when the application creates a button, for example, it gives the button a function pointer for it to call

when clicked. The button structure stores this pointer in RAM. There is no other way to do this effectively

in C: because the toolkit cannot name the function it must call, a function pointer must be used, and this

pointer must be assigned at runtime.

Another example of this is the virtual ﬁle system that UNIX/Linux kernels use. The OS might need to

access any number of ﬁle systems, and statically compiling all of them into the core kernel is problematic

(imagine having to recompile Windows just because USB storage devices become popular). So what the

OS does is interact with ﬁle systems through a VFS — virtual ﬁle system — interface. This is a set of basic

operations, such as read() and write(), which are stored in a structure. Every ﬁle system implementation

populates the structure with its own functions, then passes the structure to the core kernel. When a user

program tries to read from a CD, for example, the OS gets the VFS structure associated with a CD ﬁle and

calls the read() function pointer, allowing the core kernel to remain independent of speciﬁc ﬁle systems. The

basic approach is the same as GUI toolkits. Because of C’s naming approach, the OS has to use run-time

allocation and function pointers in order to enable ﬂexible composition and extension.

3.2 C++

C++ is similar to C, except that it richer namespaces and inheritance. In C++ the :: (double colon) generally

refers to a namespace hierarchy. For example, you can deﬁne a namespace, or a hierarchy of namespaces:

namespace test;

namespace test::more;

Listing 3.5: C++ namespaces

A class also deﬁnes a namespace:

void MyClass::doSomething() {}

Listing 3.6: The namespace of a C++ class

While classes can use a variety of access modiﬁers on their ﬁelds and methods, these do not operate at

the namespace level. In this way they are different than the static keyword in C. In C, static means that the

variable or function does not exist in the global scope, and so cannot be named: other ﬁles that try to do

so will get a “no such variable exists” error. In contrast, specifying a variable to be private in a C++ class

means that other codes can reference it, but doing so generates a compile error. For example:

剩余138页未读，继续阅读

wwkk2013

粉丝: 0
资源: 1

最新资源