Contiki 2.x操作系统手册：模块与文档指南

Contiki

5星 · 超过95%的资源需积分: 10 197 浏览量更新于2024-07-22 收藏 1.7MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

Contiki是一个开源的、高度可移植的多任务操作系统，专为内存受限的网络嵌入式系统设计。由Adam Dunkels在瑞典计算机科学研究所（Swedish Institute of Computer Science）的网络嵌入式系统组开发。它特别针对资源有限的环境，如典型的配置可能只有2千字节的RAM和40千字节的ROM。 Contiki的核心是事件驱动的内核，它允许应用程序在运行时动态加载和卸载，提供了轻量级的.protothreads。这些线程模型使得系统能够在内存有限的情况下保持高效和灵活性。它的设计目标是支持物联网(IoT)应用，尤其是那些需要低功耗和小型设备的场景。该手册详细介绍了Contiki 2.x版本的各个方面，包括目录结构、数据结构索引、文件索引、模块文档、目录文档、数据结构文档、文件文档以及示例文档。每部分都涵盖了关键的功能和组件，帮助开发者理解如何构建、配置和使用Contiki来实现物联网应用。对于中国用户来说，虽然原文可能是英文，但由于其在物联网领域的实用性，学习和理解英文文档仍然是掌握Contiki的最佳途径。通过阅读这本手册，开发者可以深入了解操作系统内部的工作原理，学习如何编写高效的代码，以及如何利用其提供的功能来优化嵌入式设备的网络通信和数据处理能力。此外，手册还强调了代码的开源特性，这意味着用户可以深入研究源码，进行定制化开发或者贡献自己的改进。这对于寻求创新和适应特定硬件或应用场景的工程师来说，是非常宝贵的学习资源。 Contiki 2.x Reference Manual是一份全面的指南，适合物联网开发者、嵌入式系统专家以及对低功耗、小型网络设备感兴趣的人员，无论是初学者还是经验丰富的开发人员，都能从中获得有价值的洞察和指导。通过掌握这份文档，用户将能够更有效地利用Contiki进行物联网项目的开发和部署。

资源详情

资源推荐

6.7 The uIP TCP/IP stack 15

by the network device driver. If the destination is not on the physically connected network, the IP packet

is forwarded onto another network by a router that is situated between the two networks. If the maximum

packet size of the other network is smaller than the size of the IP packet, the packet is fragmented into

smaller packets by the router. If possible, the size of the TCP segments are chosen so that fragmentation

is minimized. The ﬁnal recipient of the packet will have to reassemble any fragmented IP packets before

they can be passed to higher layers.

The formal requirements for the protocols in the TCP/IP stack is speciﬁed in a number of RFC documents

published by the Internet Engineering Task Force, IETF. Each of the protocols in the stack is deﬁned in one

more RFC documents and RFC1122 collects all requirements and updates the previous RFCs.

The RFC1122 requirements can be divided into two categories; those that deal with the host to host com-

munication and those that deal with communication between the application and the networking stack.

An example of the ﬁrst kind is "A TCP MUST be able to receive a TCP option in any segment" and an

example of the second kind is "There MUST be a mechanism for reporting soft TCP error conditions to

the application." A TCP/IP implementation that violates requirements of the ﬁrst kind may not be able

to communicate with other TCP/IP implementations and may even lead to network failures. Violation of

the second kind of requirements will only affect the communication within the system and will not affect

host-to-host communication.

In uIP, all RFC requirements that affect host-to-host communication are implemented. However, in order

to reduce code size, we have removed certain mechanisms in the interface between the application and

the stack, such as the soft error reporting mechanism and dynamically conﬁgurable type-of-service bits for

TCP connections. Since there are only very few applications that make use of those features they can be

removed without loss of generality.

6.7.5 Main Control Loop

The uIP stack can be run either as a task in a multitasking system, or as the main program in a singletasking

system. In both cases, the main control loop does two things repeatedly:

• Check if a packet has arrived from the network.

• Check if a periodic timeout has occurred.

If a packet has arrived, the input handler function, uip_input(), should be invoked by the main control

loop. The input handler function will never block, but will return at once. When it returns, the stack or

the application for which the incoming packet was intended may have produced one or more reply packets

which should be sent out. If so, the network device driver should be called to send out these packets.

Periodic timeouts are used to drive TCP mechanisms that depend on timers, such as delayed acknowledg-

ments, retransmissions and round-trip time estimations. When the main control loop infers that the periodic

timer should ﬁre, it should invoke the timer handler function uip_periodic(). Because the TCP/IP stack may

perform retransmissions when dealing with a timer event, the network device driver should called to send

out the packets that may have been produced.

6.7.6 Architecture Speciﬁc Functions

uIP requires a few functions to be implemented speciﬁcally for the architecture on which uIP is intended to

run. These functions should be hand-tuned for the particular architecture, but generic C implementations

are given as part of the uIP distribution.

6.7.6.1 Checksum Calculation The TCP and IP protocols implement a checksum that covers the data

and header portions of the TCP and IP packets. Since the calculation of this checksum is made over all

Generated on Mon Jul 2 14:14:41 2007 for Contiki 2.x by Doxygen

6.7 The uIP TCP/IP stack 16

bytes in every packet being sent and received it is important that the function that calculates the checksum

is efﬁcient. Most often, this means that the checksum calculation must be ﬁne-tuned for the particular

architecture on which the uIP stack runs.

While uIP includes a generic checksum function, it also leaves it open for an architecture speciﬁc imple-

mentation of the two functions uip_ipchksum() and uip_tcpchksum(). The checksum calculations in those

functions can be written in highly optimized assembler rather than generic C code.

6.7.6.2 32-bit Arithmetic The TCP protocol uses 32-bit sequence numbers, and a TCP implementation

will have to do a number of 32-bit additions as part of the normal protocol processing. Since 32-bit

arithmetic is not natively available on many of the platforms for which uIP is intended, uIP leaves the 32-

bit additions to be implemented by the architecture speciﬁc module and does not make use of any 32-bit

arithmetic in the main code base.

While uIP implements a generic 32-bit addition, there is support for having an architecture speciﬁc imple-

mentation of the uip_add32() function.

6.7.7 Memory Management

In the architectures for which uIP is intended, RAM is the most scarce resource. With only a few kilobytes

of RAM available for the TCP/IP stack to use, mechanisms used in traditional TCP/IP cannot be directly

applied.

The uIP stack does not use explicit dynamic memory allocation. Instead, it uses a single global buffer

for holding packets and has a ﬁxed table for holding connection state. The global packet buffer is large

enough to contain one packet of maximum size. When a packet arrives from the network, the device driver

places it in the global buffer and calls the TCP/IP stack. If the packet contains data, the TCP/IP stack

will notify the corresponding application. Because the data in the buffer will be overwritten by the next

incoming packet, the application will either have to act immediately on the data or copy the data into a

secondary buffer for later processing. The packet buffer will not be overwritten by new packets before the

application has processed the data. Packets that arrive when the application is processing the data must be

queued, either by the network device or by the device driver. Most single-chip Ethernet controllers have

on-chip buffers that are large enough to contain at least 4 maximum sized Ethernet frames. Devices that

are handled by the processor, such as RS-232 ports, can copy incoming bytes to a separate buffer during

application processing. If the buffers are full, the incoming packet is dropped. This will cause performance

degradation, but only when multiple connections are running in parallel. This is because uIP advertises

a very small receiver window, which means that only a single TCP segment will be in the network per

connection.

In uIP, the same global packet buffer that is used for incoming packets is also used for the TCP/IP headers

of outgoing data. If the application sends dynamic data, it may use the parts of the global packet buffer that

are not used for headers as a temporary storage buffer. To send the data, the application passes a pointer to

the data as well as the length of the data to the stack. The TCP/IP headers are written into the global buffer

and once the headers have been produced, the device driver sends the headers and the application data out

on the network. The data is not queued for retransmissions. Instead, the application will have to reproduce

the data if a retransmission is necessary.

The total amount of memory usage for uIP depends heavily on the applications of the particular device in

which the implementations are to be run. The memory conﬁguration determines both the amount of trafﬁc

the system should be able to handle and the maximum amount of simultaneous connections. A device that

will be sending large e-mails while at the same time running a web server with highly dynamic web pages

and multiple simultaneous clients, will require more RAM than a simple Telnet server. It is possible to run

the uIP implementation with as little as 200 bytes of RAM, but such a conﬁguration will provide extremely

low throughput and will only allow a small number of simultaneous connections.

Generated on Mon Jul 2 14:14:41 2007 for Contiki 2.x by Doxygen

6.7 The uIP TCP/IP stack 17

6.7.8 Application Program Interface (API)

The Application Program Interface (API) deﬁnes the way the application program interacts with the TCP/IP

stack. The most commonly used API for TCP/IP is the BSD socket API which is used in most Unix systems

and has heavily inﬂuenced the Microsoft Windows WinSock API. Because the socket API uses stop-and-

wait semantics, it requires support from an underlying multitasking operating system. Since the overhead

of task management, context switching and allocation of stack space for the tasks might be too high in the

intended uIP target architectures, the BSD socket interface is not suitable for our purposes.

uIP provides two APIs to programmers: protosockets, a BSD socket-like API without the overhead of full

multi-threading, and a "raw" event-based API that is nore low-level than protosockets but uses less memory.

See also:

Protosockets library

Protothreads

6.7.8.1 The uIP raw API The "raw" uIP API uses an event driven interface where the application is

invoked in response to certain events. An application running on top of uIP is implemented as a C function

that is called by uIP in response to certain events. uIP calls the application when data is received, when

data has been successfully delivered to the other end of the connection, when a new connection has been

set up, or when data has to be retransmitted. The application is also periodically polled for new data. The

application program provides only one callback function; it is up to the application to deal with mapping

different network services to different ports and connections. Because the application is able to act on

incoming data and connection requests as soon as the TCP/IP stack receives the packet, low response times

can be achieved even in low-end systems.

uIP is different from other TCP/IP stacks in that it requires help from the application when doing re-

transmissions. Other TCP/IP stacks buffer the transmitted data in memory until the data is known to be

successfully delivered to the remote end of the connection. If the data needs to be retransmitted, the stack

takes care of the retransmission without notifying the application. With this approach, the data has to be

buffered in memory while waiting for an acknowledgment even if the application might be able to quickly

regenerate the data if a retransmission has to be made.

In order to reduce memory usage, uIP utilizes the fact that the application may be able to regenerate sent

data and lets the application take part in retransmissions. uIP does not keep track of packet contents af-

ter they have been sent by the device driver, and uIP requires that the application takes an active part in

performing the retransmission. When uIP decides that a segment should be retransmitted, it calls the appli-

cation with a ﬂag set indicating that a retransmission is required. The application checks the retransmission

ﬂag and produces the same data that was previously sent. From the application’s standpoint, performing

a retransmission is not different from how the data originally was sent. Therefore the application can be

written in such a way that the same code is used both for sending data and retransmitting data. Also, it is

important to note that even though the actual retransmission operation is carried out by the application, it

is the responsibility of the stack to know when the retransmission should be made. Thus the complexity of

the application does not necessarily increase because it takes an active part in doing retransmissions.

Application Events The application must be implemented as a C function, UIP_APPCALL(), that uIP

calls whenever an event occurs. Each event has a corresponding test function that is used to distinguish

between different events. The functions are implemented as C macros that will evaluate to either zero or

non-zero. Note that certain events can happen in conjunction with each other (i.e., new data can arrive at

the same time as data is acknowledged).

The Connection Pointer When the application is called by uIP, the global variable uip_conn is set to

point to the uip_conn structure for the connection that currently is handled, and is called the "current

Generated on Mon Jul 2 14:14:41 2007 for Contiki 2.x by Doxygen

6.7 The uIP TCP/IP stack 18

connection". The ﬁelds in the uip_conn structure for the current connection can be used, e.g., to distinguish

between different services, or to check to which IP address the connection is connected. One typical

use would be to inspect the uip_conn->lport (the local TCP port number) to decide which service the

connection should provide. For instance, an application might decide to act as an HTTP server if the value

of uip_conn->lport is equal to 80 and act as a TELNET server if the value is 23.

Receiving Data If the uIP test function uip_newdata() is non-zero, the remote host of the connection has

sent new data. The uip_appdata pointer point to the actual data. The size of the data is obtained through

the uIP function uip_datalen(). The data is not buffered by uIP, but will be overwritten after the application

function returns, and the application will therefor have to either act directly on the incoming data, or by

itself copy the incoming data into a buffer for later processing.

Sending Data When sending data, uIP adjusts the length of the data sent by the application according to

the available buffer space and the current TCP window advertised by the receiver. The amount of buffer

space is dictated by the memory conﬁguration. It is therefore possible that all data sent from the application

does not arrive at the receiver, and the application may use the uip_mss() function to see how much data

that actually will be sent by the stack.

The application sends data by using the uIP function uip_send(). The uip_send() function takes two argu-

ments; a pointer to the data to be sent and the length of the data. If the application needs RAM space for

producing the actual data that should be sent, the packet buffer (pointed to by the uip_appdata pointer) can

be used for this purpose.

The application can send only one chunk of data at a time on a connection and it is not possible to call

uip_send() more than once per application invocation; only the data from the last call will be sent.

Retransmitting Data Retransmissions are driven by the periodic TCP timer. Every time the periodic

timer is invoked, the retransmission timer for each connection is decremented. If the timer reaches zero,

a retransmission should be made. As uIP does not keep track of packet contents after they have been sent

by the device driver, uIP requires that the application takes an active part in performing the retransmission.

When uIP decides that a segment should be retransmitted, the application function is called with the uip_-

rexmit() ﬂag set, indicating that a retransmission is required.

The application must check the uip_rexmit() ﬂag and produce the same data that was previously sent. From

the application’s standpoint, performing a retransmission is not different from how the data originally was

sent. Therefor, the application can be written in such a way that the same code is used both for sending data

and retransmitting data. Also, it is important to note that even though the actual retransmission operation is

carried out by the application, it is the responsibility of the stack to know when the retransmission should

be made. Thus the complexity of the application does not necessarily increase because it takes an active

part in doing retransmissions.

Closing Connections The application closes the current connection by calling the uip_close() during an

application call. This will cause the connection to be cleanly closed. In order to indicate a fatal error, the

application might want to abort the connection and does so by calling the uip_abort() function.

If the connection has been closed by the remote end, the test function uip_closed() is true. The application

may then do any necessary cleanups.

Reporting Errors There are two fatal errors that can happen to a connection, either that the connection

was aborted by the remote host, or that the connection retransmitted the last data too many times and has

been aborted. uIP reports this by calling the application function. The application can use the two test

functions uip_aborted() and uip_timedout() to test for those error conditions.

Generated on Mon Jul 2 14:14:41 2007 for Contiki 2.x by Doxygen

6.7 The uIP TCP/IP stack 19

Polling When a connection is idle, uIP polls the application every time the periodic timer ﬁres. The

application uses the test function uip_poll() to check if it is being polled by uIP.

The polling event has two purposes. The ﬁrst is to let the application periodically know that a connection is

idle, which allows the application to close connections that have been idle for too long. The other purpose

is to let the application send new data that has been produced. The application can only send data when

invoked by uIP, and therefore the poll event is the only way to send data on an otherwise idle connection.

Listening Ports uIP maintains a list of listening TCP ports. A new port is opened for listening with the

uip_listen() function. When a connection request arrives on a listening port, uIP creates a new connection

and calls the application function. The test function uip_connected() is true if the application was invoked

because a new connection was created.

The application can check the lport ﬁeld in the uip_conn structure to check to which port the new connection

was connected.

Opening Connections New connections can be opened from within uIP by the function uip_connect().

This function allocates a new connection and sets a ﬂag in the connection state which will open a TCP

connection to the speciﬁed IP address and port the next time the connection is polled by uIP. The uip_-

connect() function returns a pointer to the uip_conn structure for the new connection. If there are no free

connection slots, the function returns NULL.

The function uip_ipaddr() may be used to pack an IP address into the two element 16-bit array used by uIP

to represent IP addresses.

Two examples of usage are shown below. The ﬁrst example shows how to open a connection to TCP port

8080 of the remote end of the current connection. If there are not enough TCP connection slots to allow

a new connection to be opened, the uip_connect() function returns NULL and the current connection is

aborted by uip_abort().

void connect_example1_app(void) {

if(uip_connect(uip_conn->ripaddr, HTONS(8080)) == NULL) {

uip_abort();

}

The second example shows how to open a new connection to a speciﬁc IP address. No error checks are

made in this example.

void connect_example2(void) {

uip_addr_t ipaddr;

uip_ipaddr(ipaddr, 192,168,0,1);

uip_connect(ipaddr, HTONS(8080));

}

6.7.9 Examples

This section presents a number of very simple uIP applications. The uIP code distribution contains several

more complex applications.

6.7.9.1 A Very Simple Application This ﬁrst example shows a very simple application. The applica-

tion listens for incoming connections on port 1234. When a connection has been established, the application

replies to all data sent to it by saying "ok"

Generated on Mon Jul 2 14:14:41 2007 for Contiki 2.x by Doxygen

剩余329页未读，继续阅读

辛昕

粉丝: 2
资源: 11

Contiki 2.x操作系统手册：模块与文档指南

Contiki使用教程.docx

Contiki+STM8L

contiki 2.5

Contiki 2.2.3

contiki源码

redes_contiki:回购contiki传感器测试

contiki_contiki 微型操作系统介绍文档

Contiki 学习笔记

CONTIKI家电控制

contiki学习资料

contiki 学习资料

contiki 学习笔记

contiki-2.4

contiki编程例程

msp430 contiki

contiki资料合集

contiki 移植

contiki 430

最新资源