本文內(nèi)容來源為contiki英文介紹，自己為了學習，將其大致翻譯成中文，以便了解。

歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明來源，如果有什么翻譯不合適的地方，請留言指出，相互交流學習。

?

介紹

Contiki是一個開放源碼、多任務(wù)事件驅(qū)動的嵌入式網(wǎng)絡(luò)專用操作系統(tǒng)，輕量級的資源占用使得它很適合存儲資源緊張的微控制器。

Contiki由幾個獨立的模塊組成，包括一個類似線程的多任務(wù)事件驅(qū)動protothread庫，uIP TCP/IP(v4 and v6)協(xié)議棧，無線傳感網(wǎng)絡(luò)協(xié)議棧Rime。

Contiki是為了網(wǎng)絡(luò)應(yīng)用而設(shè)計，但也可以基于它的內(nèi)核開發(fā)其他應(yīng)用。這時它的官方網(wǎng)站。official website

事件

contiki內(nèi)核是基于事件驅(qū)動的，這意味著每個正在執(zhí)行的應(yīng)用都對于的一個事件的響應(yīng)。整個應(yīng)用包括kernel、libraries、user code可能包含若干個正在執(zhí)行的進程。

不同的進程通常指執(zhí)行特定的時間，然后等待事件的發(fā)生。在等待期間，進程處于阻塞狀態(tài)。當事件發(fā)生時，內(nèi)核將傳遞關(guān)于事件發(fā)生的消息，并且激活那些等待事件發(fā)生的進程。時間可以分為以下三類。

時間事件

一個進程可以設(shè)定一個定時器，在指定的時間后產(chǎn)生一個事件，它自己會阻塞，直到時間期滿后，繼續(xù)運行。這對于一些周期性的操作或者網(wǎng)絡(luò)協(xié)議，例如同步相關(guān)的問題是，很有幫助。

外部事件

通過微控制器的具有中斷功能的IO口連接的外部設(shè)備，當觸發(fā)條件滿足時，可以產(chǎn)生事件。例如，一個按鈕、接收射頻數(shù)據(jù)、加速度檢測計都是可以外部中斷源。進程會依據(jù)與這些事件來響應(yīng)。

內(nèi)部事件

任何進程都有可能處理其他進程的事件，或者發(fā)向自己的事件，這對于進程間通訊很有幫助。一個進程可以通知另一個進程，相關(guān)數(shù)據(jù)已經(jīng)準備好。

事件一般是被發(fā)送的，一個中斷服務(wù)程序執(zhí)行時，可能向其他進程發(fā)起一個事件。一個事件通常具有以下幾個信息：

process：事件將要發(fā)向的進程，可以發(fā)向某一個進程，也可以發(fā)向所有登記過的進程。

event type：事件類型，用戶可以針對進程，自定義事件類型，以便于進程區(qū)分。例如發(fā)送和接收包時的事件

data：可選項，一些數(shù)據(jù)可能需要隨同事件一起發(fā)向進程

?

進程

進程在Contiki是任務(wù)的同義詞。進程機制使用protothread庫。一個進程是一個C函數(shù)，很有可能包含一個無限循環(huán)和一些阻塞的宏調(diào)用。由于Contiki的事件驅(qū)動內(nèi)核不是可搶占的，每個進程在執(zhí)行時，會獨享處理器，直到它由于等待事件而阻塞。不同的阻塞類型由不同的宏來定義實現(xiàn)。這允許編程狀態(tài)機作為一個順序控制流。下面給出的是一個contiki官方網(wǎng)站給出的一般進程結(jié)構(gòu)：

#include "contiki.h"/* The PROCESS() statement defines the process' name. */ PROCESS(my_example_process, "My example process");/* The AUTOSTART_PROCESS() statement selects what process(es)to start when the module is loaded. */ AUTOSTART_PROCESSES(&my_example_process);/* The PROCESS_THREAD() contains the code of the process. */ PROCESS_THREAD(my_example_process, ev, data) {/* Do not put code before the PROCESS_BEGIN() statement -such code is executed every time the process is invoked. */PROCESS_BEGIN();/* Initialize stuff here. */while(1) {PROCESS_WAIT_EVENT();/* Do the rest of the stuff here. */}/* The PROCESS_END() statement must come at the end of thePROCESS_THREAD(). */PROCESS_END(); }

這段代碼沒做任何事情，僅僅是一個進程的框架結(jié)構(gòu)。重復(fù)性的等待事件發(fā)生，然后執(zhí)行，然后再等待….

當使用protothread來編程時，有以下幾點要注意：

1. 本地變量是不保存的。

???? 當一個進程調(diào)用一個阻塞宏時，實際上發(fā)生的是進程函數(shù)已經(jīng)返回了，控制權(quán)交給內(nèi)核去調(diào)度其他進程。當事件發(fā)生時，內(nèi)核會調(diào)用相同的進程函數(shù)，它會調(diào)到發(fā)生等待事件，阻塞的地方繼續(xù)執(zhí)行。因此，如果進程的本地變量(非static變量)在阻塞前被賦值，那么，當阻塞后返回時，這些變量保存的值將失效。一個好的解決方法是使用static變量。

2. 不要使用switch語句

???? protothreads使用本地local continuations去恢復(fù)阻塞退出后的堆棧狀態(tài)。這是通過switch來實現(xiàn)的。如果case表達式可以放置在任何位置(在if里面或者while段里面)，它不能再和其他switch語句混合使用了。因此，在進程函數(shù)里面，最好不要使用switch語句。

?

uIP TCP/IP stack

contiki包含一個輕量級的TCP/IP協(xié)議棧，名為uIP。它實現(xiàn)了RFC兼容的IPv4、IPv6、TCP和UDP。后兩者兼容IPv4和IPv6.uIP非常精簡，僅實現(xiàn)最為重要的功能。例如，整個協(xié)議棧只有一個buffer，用來接受和發(fā)送數(shù)據(jù)包。

應(yīng)用API

基于uIP協(xié)議棧，有兩種方式來編程。

raw API：uIP raw API適合實現(xiàn)簡單應(yīng)用。例如一個簡單的能夠監(jiān)聽一些TCP端口的簡單回顯服務(wù)器。隨著不斷的發(fā)展，它也可以編寫功能復(fù)雜的網(wǎng)絡(luò)程序。

protosocket API：protosocket API利用protothread庫來實現(xiàn)更加靈活的TCP/IP應(yīng)用程序。它提供類似于標準BSN socket的接口，允許在進程中編寫應(yīng)用。

Lower Layers

擁有TCP/IP功能的協(xié)議棧和一些應(yīng)用程序很好，但是它還可以做的更好。uIP要求一個更低層去和附近節(jié)點通訊。有兩種節(jié)點。

nodes：在nodes之間通訊需要無線連接。uIP支持無線收發(fā)數(shù)據(jù)包。基于uIP的版本配置，Contiki遵循不同的方向。

1. 當傳輸?shù)臑镮Pv6數(shù)據(jù)包時，Contiki選擇route-over配置。因此，uIP6使用一個成為sicslowmac的MAC層來處理無線數(shù)據(jù)包。頭部壓縮技術(shù)由6lowpan模塊提供，它可以轉(zhuǎn)發(fā)數(shù)據(jù)包。

2. 針對IPv4通訊，Contiki選擇mesh-under配置。這由Rime通訊協(xié)議棧來負責。Rime提供mesh路由和路由發(fā)現(xiàn)，因此，uIP通過它，可以轉(zhuǎn)發(fā)網(wǎng)絡(luò)數(shù)據(jù)包。從IP的角度來看，需要本地網(wǎng)絡(luò)的所有傳感器節(jié)點、甚至是多跳中繼節(jié)點是需要的。

gateways：為了與無線傳感器網(wǎng)絡(luò)之外的網(wǎng)絡(luò)通訊，網(wǎng)關(guān)是必須的。它是連接傳感器網(wǎng)絡(luò)和其他網(wǎng)絡(luò)的橋梁。在大多數(shù)情況下，網(wǎng)關(guān)由PC來擔當，當然，它也可以是嵌入式設(shè)備。PC和節(jié)點通過串口連接，IP數(shù)據(jù)包使用SLIP在兩者之間傳輸。在PC端，必須允許轉(zhuǎn)換程序，來轉(zhuǎn)換串行線路和網(wǎng)絡(luò)接口之間的數(shù)據(jù)轉(zhuǎn)換。基于uIP的版本，功能有所不同。

1. uIPv6，一個將數(shù)據(jù)包在射頻數(shù)據(jù)轉(zhuǎn)和串行數(shù)據(jù)之間進行相互轉(zhuǎn)換的程序是很有必要的，它不需要做任何的地址比較功能，除了IPv6的頭壓縮和解壓機制外(6lowapn)，它沒有任何的其他的IP棧。從PC的角度出發(fā)，這個節(jié)點充當一個以太網(wǎng)的接口，因此，PC可以做任何工作。

2. uIPv4，它的工作機制就完全不同了。連接到PC的節(jié)點充當網(wǎng)關(guān)的角色，帶有所有的IP棧。它發(fā)送的每個數(shù)據(jù)包，都會檢測它的IP地址。如果數(shù)據(jù)無線傳感器網(wǎng)絡(luò)的范圍，則會通過射頻通道來發(fā)送。否則，會通過串行鏈路發(fā)給PC。PC上運行的程序?qū)?gòu)建一個IP網(wǎng)絡(luò)接口。

Rime stack

Rime stack提供一個層次分明的無線網(wǎng)絡(luò)協(xié)議棧集合,從一個簡單的匿名廣播到復(fù)雜的網(wǎng)狀路由.實現(xiàn)這一些列復(fù)雜協(xié)議肯定需要分層、分模塊來進行的。復(fù)雜模塊的實現(xiàn)基于簡單模塊的實現(xiàn)。下圖是Rime協(xié)議的概覽。

Rime每個模塊的簡要描述：

1. abc： 異步廣播模塊，它僅僅通過射頻通道發(fā)送數(shù)據(jù)包，從射頻通道接收所有的數(shù)據(jù)包，并且傳遞給高層協(xié)議，屬于Rime中最底層的模塊。

2. broadcast：指定廣播。它向輸出數(shù)據(jù)包中添加了源地址，并且將數(shù)據(jù)包傳遞給abc模塊。

3. unicast：往數(shù)據(jù)包中增加目的地址，并傳遞給broadcast模塊。在接收端，如果接受包的目的地址和節(jié)點地址不匹配，則丟棄該包。

4. stunicast：stubborn的單播，當需要向節(jié)點發(fā)送數(shù)據(jù)包時，它以一個給定的時間周期，反復(fù)的發(fā)送數(shù)據(jù)包，直到被暫停。該模塊不單獨使用，通常由高層來調(diào)用。

5. runicast：可靠的單播。它通過調(diào)用stunicast來發(fā)送數(shù)據(jù)包，并且等待ACK響應(yīng)。當接收到ACK響應(yīng)時，它停止持續(xù)的發(fā)送數(shù)據(jù)包。此時，為了避免無限制的發(fā)送數(shù)據(jù)包，需要制定一個最大重傳次數(shù)。

6. polite和ipolite：這兩個模塊幾乎是相同的。當一個數(shù)據(jù)包需要在指定幀中被傳送，這個模塊會等待一半的時間，然后檢查它是否收到了準備要發(fā)送的數(shù)據(jù)包。如果收到了，該數(shù)據(jù)包不會發(fā)送。否則，他會發(fā)送數(shù)據(jù)包。這在避免不必要的重傳中有用處。

7.multihop：這個模塊需要一個路由表功能，當它要發(fā)送數(shù)據(jù)包時，它查找路由表尋找下一跳地址，通過unicast向其發(fā)送數(shù)據(jù)包。當它接收到一個數(shù)據(jù)包時，如果節(jié)點是接收數(shù)據(jù)包的目標地址，該數(shù)據(jù)包被傳往上層，否則，它會查找路由表，確定下一跳地址并且轉(zhuǎn)發(fā)它。

MAC layer

正如我們所看到的,uIPv6協(xié)議棧使用一個簡單的MAC層協(xié)議，成為sicslomac，沒有其他選項。然而，IPv4棧使用Rime作為它的底層協(xié)議實現(xiàn)，可以選擇特定的MAC層。

在Contiki中，以下的MAC層已經(jīng)實現(xiàn)了。

1. nullmac： 正如它名字一樣，它不做其他事情，僅僅是在上層應(yīng)用和射頻驅(qū)動之前轉(zhuǎn)發(fā)數(shù)據(jù)包。

2. xmac協(xié)議：前導采樣協(xié)議，節(jié)點周期性的監(jiān)聽射頻通道。

3. lpp協(xié)議：probing協(xié)議，節(jié)點周期性地發(fā)送一小段信息，說他們正在監(jiān)聽，監(jiān)聽一段時間后，他們轉(zhuǎn)入休眠狀態(tài)。

?

目前為止的工作情況

在WSN430平臺上已經(jīng)移植并且測試了如下幾點。

1. kernel：基本的contiki工作沒有問題，包括進城處理，不同的時間管理等等。此外，Contiki要求的所有驅(qū)動都在WSN430開發(fā)包中提供，在Contiki舊的開發(fā)包中，這些是系統(tǒng)的一部分，考慮到可維護因素，他們被分離了。

2. uIP：uIP在IPv4和IPv6下工作都沒有問題，TCP和UDP都是可用的。需要注意的一點是，UDP的最大段長度，通常需要設(shè)置為128個字節(jié)。節(jié)點之間的通訊，可以直接通過射頻，或者使用PC連接的gateway。

3. Rime：無線傳感器協(xié)議棧部分已經(jīng)被測試了，一些簡單的模塊能夠正常工作了，例如abc, broadcast, unicast, ipolite, stunicast, runicast, multihop。使用mesh的全部的通訊協(xié)議棧已經(jīng)證實可以在同樣的信道和其他節(jié)點協(xié)同工作。多跳和路由暫時沒有測試。

4. MAC層：之前提到的四個MAC層協(xié)議已經(jīng)針對WSN430平臺配置好了。nullmac, xmac, lpp and sicslomac.

例子

詳見Contiki Example Page

下載

Here is the archives, the Contiki OS ported for the WSN430, along with the examples:

• contiki-wsn430-v1.3.tar.gz

  • updated to Contiki_2.4

  • added wsn430v14 support, with cc2420 radio chip

  • added tools to run SLIP from Senslab Virtual Machines

?

?

網(wǎng)址原文鏈接:http://senstools.gforge.inria.fr/doku.php?id=os:contiki

轉(zhuǎn)載于:https://www.cnblogs.com/cherishui/p/3709498.html

總結(jié)

以上是生活随笔為你收集整理的Contiki系统介绍的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。