Contiki系統進程與事件剖析

馮韜+朱立才

摘 要： Contiki在物聯網中的應用越來廣泛，但用戶對系統的認識卻相對滯后。Contiki是一款適用于資源受限無線傳感網操作系統，支持IPv6協議。在事件驅動的基礎上，提供protothread線程模型，從而有效節省內存空間。文章介紹了Contiki的特點，結合main函數的執行流程深入剖析了Contiki的進程與事件以及事件與進程的關系。通過實例在Cooja下進行了仿真，并對結果進行了分析。

關鍵詞： Contiki； 進程； 事件； protothread

中圖分類號：TP316 文獻標志碼：A 文章編號：1006-8228（2016）12-01-04

Analysis of process and event of Contiki system

Feng Tao， Zhu Licai

（School of Information Science and Technology， Yancheng teacher's University， Yancheng， Jiangsu 224002， China）

Abstract： The application of Contiki system in the Internet of Things is more and more extensive， but the user's cognition of the system is relatively backward. Contiki is suitable for resource constrained wireless sensor networks， supports the IPv6 protocol， and on the basis of event driven， provides the protothreads threading model， which can effectively save memory space. In this paper， the characteristics of Contiki are introduced， combined with the execution process of the main function， the process and event of Contiki， and the relationship between them are analyzed. And an example is simulated with Cooja， the results are analyzed.

Key words： Contiki； process； event； protothreads

0 引言

無線傳感器是無線傳感網的核心部件，一般的無線傳感器具有低能量、低處理能力、低存儲能力和低數據傳輸速率的特點。因此，傳統的操作系統不適用于無線傳感網，需要研制適用的操作系統。目前應用于無線傳感網的操作系統有TinyOS，μC/OS-Ⅱ，Contiki[1]等。Contiki是一款開源的、高度可移植的多任務操作系統，適用于需聯網的嵌入式系統和無線傳感器。該系統適用于資源受限的嵌入式單片機系統，典型情況下只需2K的RAM和40K的FLASH存儲器，可移植到多種平臺上。Contiki是基于事件驅動內核操作系統，在該內核上，應用程序可以在運行時動態加載。在事件驅動內核的基礎上，提供了protothead線程模型，使多個線程共享一個任務棧，從而減少內存占用。具體來說，Contiki具有以下特點：事件驅動的多任務內核，多個任務可以共享一個棧；支持全IP網絡，如IPv4，UDP，TCP和HTTP[2]，支持低功耗有損網絡協議，如6lowpan，RPL，CoAP[3]等；提供了能量耗費評估機制[2]；支持運行時模塊的動態鏈接和加載；提供內存塊分配、托管內存分配器和標準的C內存分配器[2]三種內存分配方法；集成無線傳感網絡仿真工具Cooja[4]和MSP430[5]；提供CFS文件系統[6]。

正因為Contiki系統具有的優越性，使其在學術界和工業界得到越來越廣泛的重視。但Contiki的運行機制比較特殊，源碼編寫技巧性強，研究者往往無從入手。本文深入剖析Contiki的進程與事件，闡述兩者之間的關系，并對之進行仿真，以便為Contiki的研究人員和開發人員提供一定的參考。

1 Contiki進程

Contiki使用事件驅動和Protothread兩個主要的機制[1]，前者能達到降低功耗的目的，后者可有效節省內存空間。

傳統操作系統每個進程需要一個獨立的棧，這個特點不適用于內存資源極度受限的無線傳感設備。Contiki提供的Protothread機制解決了這個問題，通過保存被阻塞的進程行數來實現進程切換，而這在系統中只需兩個字節即可實現。當該進程下一次被調用時，通過switch（_LINE_）進行跳轉，恢復進程的執行[7]。通過這種機制，能有效節省內存空間。

1.1 Contiki編程模型

本文結合Contiki2.7中提供的例程Hello World給出Contiki的編程模型。

在該結構中包含進程名稱（*name）、執行進程的宏（PT_THREAD）、用于保存程序被中斷行數的結構體（pt）、程序狀態（state）和進程優先級。

分別表示進程已退出，但還沒有從進程鏈表中刪除；進程已放于執行隊列，還沒有取得執行權；進程取得執行權并投入運行。

進程優先級needspoll，即當系統調用process_run（）函數時，有所needspoll標志為1的進程投入運行，之后才會從事件隊列取出下一個事件傳遞給相應的監聽進程。

1.3 進程鏈表

Contiki將進程組織成一個鏈表結構，一個頭指針process_list指向該表頭，通過遍歷鏈表處理進程。

2 Contiki事件

為了節省能耗，嵌入式系統將周圍環境的變化看成一個個事件，事件到來，系統進程處理，否則，系統就處于休眠狀態。

Contiki將所有事件存放于一個全局的靜態數組中，數組采用環形結構。事件數目在系統運行之前就要指定（用戶可以通過PROCESS_CONF_NUMEVENTS配置其大小），通過數組下標可以快速訪問事件。系統還定義兩個全局靜態變量nevents和fevent，分別用于記錄未處理事件總數及下一個待處理的位置。

因此對于Contiki系統而言，事件遵循先到先服務策略。

2.1 事件產生

Conitki有兩種產生事件的方式，即同步方式和異步方式。同步事件通過process_post_synch函數產生，事件觸發后直接處理（調用call_process函數）。而異步事件產生是由process_post產生，產生后放入事件隊列等待處理。

2.2 事件調度

do_event函數用于處理事件。它首先取出該事件，由于采用環形數組存放待處理的事件，所以在計算未處理事件總數及下一個待處理事件的數組下標時，需用取余操作。然后判斷事件是否為廣播事件PROCESS_BROADCAST，由于處理廣播事件可能需要更多的時間，為保證系統實時性，先運行高優先級的進程，然后再去處理事件（調用call_process函數）。如果事件是初始化事件PROCESS_EVENT_INIT（創建進程的時候會觸發此事件），需要將進程狀態設為PROCESS_STATE_RUNNING。

2.3 事件處理

call_process會調用thread函數處理事件。

2.4 事件的數據結構

struct event_data

{ process_event_t ev；

process_data_t data；

struct process *p；

}；

typedef unsigned char process_event_t；

typedef void * process_data_t；

上述結構體含義為：標識產生的事件（ev）、給進程傳輸的數據（data）以及監聽該事件的進程（p）。

2.5 事件的分類

Contiki系統的事件可分為三類：時鐘事件、外部事件和內部事件。時鐘事件可以看成是特殊的內部事件。

⑴ 系統事件

系統定義了10個事件，以0x80～0x8a標識。如：

⑵ 定時器事件

Contiki系統包括五種定時器：

timer和stimer：提供了最簡單的時鐘操作，即檢查時鐘周期是否已經結束。兩種時鐘最大的不同在于，tmier使用系統時鐘的ticks，而stimer是使用的秒。

ctimer：活動時鐘。當它過期時，調用一個函數。

etimer：活動時鐘。當它過期時，發送一個事件。

rtimer：實時時鐘。在某個確定的時間調用一個函數。

3 進程、事件和etimer之間的關系

3.1 事件與etimer關系

etimer_process執行時，會遍歷整個etimer鏈表，檢查etimer是否有到期的，如有到期的就把事件PROCESS_EVENT_TIMER加入到事件隊列中，并將該etimer成員變量p指向PROCESS_NONE。PROCESS_NONE用于標識該etimer是否到期，函數etimer_expired會根據etimer的p是否指向PROCESS_NONE來判斷該etimer是否到期。

3.2 進程與etimer關系

etimer是一種特殊事件。etimer與process并不是一一對應的關系，即一個etimer必定綁定一個process，但process不一定非得綁定etimer。

3.3 進程與事件關系

當有事件傳遞給進程時，就新建一個事件加入事件隊列，并綁定該進程，所以一個進程可以對應于多個事件，而一個事件可以廣播給所有進程，即該事件成員變量p指向空。當調用do_event函數時，將進程鏈表所有進程投入運行。

在Contiki中每一種硬件平臺都對一個相應的main源程序，在該程序中含有main函數，嵌入式系統不斷運行著main函數中的循環。本文以Contiki 2.7中的

main（）函數的主要執行過程如下。

⑴ 硬件初始化：根據不同的硬件平臺，對相關的硬件進行初始化，包括串口、網絡等。

⑵ 時鐘初始化：對系統時鐘進行初始化，不同的平臺所使用的時鐘會有所不同。

⑶ 進程初始化：Process_init（）函數主要是完成事件隊列和進程鏈表初始化。

⑷ 啟動系統進程：特別是與時鐘相關的進程，完成系統的特定功能。

⑸ 啟動用戶指定自動運行的進程。

⑹ 進入事件處理的循環：遍歷所有高優先級的進程并執行，然后轉去處理事件隊列的一個事件，將該事件與進程綁定。主要包括如下階段。

創建進程：由宏PROCESS完成，主要包括兩個方面，一是定義一個進程控制塊，二是定義進程執行體的函數。

啟動進程：由process_start（）函數啟動一個進程，如果進程不在鏈表中，將進程加入進程鏈表，并給該進程發一個初始化事件PROCESS_EVENT_ INIT，初始化進程的運行狀態，將lc設為0。

進程退出：執行退出進行函數exit_process。先進行參數驗證，確保進程在進程鏈表中并且不是PROCESS_STATE_NONE狀態，向所有進程發一個同步事件PROCESS_EVENT_EXITED。

4 仿真與分析

為驗證進程的交互過程，本實驗設置了兩個進程First和Second，同時使用了etime事件。在Cooja下的仿真結果如圖1所示。

系統啟動時，會進行一系列初始化工作，接著啟動系統進程etimer_process，進而啟動進程First和Second。當進程First執行到PROCESS_WAIT_EVENT

_UNTIL（ev==PROCESS_EVENT_TIMER），由于etimer還沒到期，進程被掛起，轉去執行Second進程，當執行到PROCESS_系統啟動時，會進行一系列初始化工作，接著啟動系統進程etimer_process，進而啟動進程First和Second。當進程First執行到PROCESS_WAIT

_EVENT_UNTIL（ev==PROCESS_EVENT_TIMER），由于etimer還沒到期，進程被掛起，轉去執行Second進程，當執行到PROCESS_WAIT_EVENT_UNTIL（ev==event_data_ready）時，由第一個進程還沒有執行post事件，該進程也被掛起。而后再轉去執行系統進程etimer_process，直到檢測到etimer到期，輸出Etime expired，然后輸出First process，并傳遞事件event_ data_ready給Second進程，重新初始化timer，再次執行First進程，由于etime沒有到期，而post事件已執行，所以會轉去執行Second進程，輸出Second process。待執行到PROCESS_WAIT_EVENT_UNTIL（ev==event

_data_ready）又被掛起，再次執行系統進程etimer_process。如此反復在兩個進程間進行調度[8]。

5 結束語

Contiki的事件驅動機制和Protothread線程模型非常適用于資源受限的無線傳感器網絡。本文在給出Contiki系統特點的基礎上，詳細分析了Contiki的事件結構，進程結構，以及進程和事件的關系，并通過main函數剖析了Contiki程序的執行流程，進一步闡述了事件和進程的關系。通過Cooja下對兩個進程交互過程仿真，以及etime事件的應用，直觀地反映三者之間的關系。接下來的工作將對系統源碼作進一步分析，為系統的移植和使用Cooja進行協議的仿真打下基礎。

參考文獻（References）：

[1] Dunkels A， Gronvall B， Voigt T.Contiki-a lightweight and

flexible operating system for tiny networked sensors.Local Computer Networks[C].Washington， USA： IEEE，2004：455-462

[2] Contiki community. Why Choose Contiki？http：// www.

contiki-os.org/index.html#why

[3] Kovatsch M， Duquennoy S， Dunkels A.A low-power coap

for contiki. Adhoc and Sensor Systems （MASS）[C].Valencia， Spanish： IEEE，2011：855-860

[4] Kugler P， Nordhus P， Eskofier B. Shimmer， Cooja and

Contiki： A new toolset for the simulation of on-node signal processing algorithms. Sensor Networks[C]. Cambridge， Massachusetts， USA： IEEE，2013：1-6

[5] Eriksson J， Osterlind F， Voigt T， Finne N， Raza S， Tsiftes

N， Dunkels A.Demo abstract： Accurate power profiling of sensornets with the cooja/mspsim simulator. Mobile Adhoc and Sensor Systems[C]. Macau， China： IEEE，2009：1060-1061

[6] Tsiftes N， Dunkels A， He Z， Voigt T.Enabling large-scale

storage in sensor networks with the coffee file system. Information Processing in Sensor Networks[C]. San Francisco， USA：IEEE，2009：349-360

[7] 蘇鉛坤.無線傳感器網絡文件系統與重編程技術研究[D].電

子科技大學，2013.

[8] Oikonomou G， Phillips I. Experiences from porting the

Contiki operating system to a popular hardware platform. Distributed Computing in Sensor Systems and Workshops[C]. Barcelona， Spanish： IEEE，2011：1-6