Contiki調用protothread程序設計

Contiki是一個開源的、高度可移植的多任務操作系統，適用于聯網嵌入式系統和無線傳感器網絡，Contiki適用于存儲器資源十分受限的嵌入式單片機系統，典型的配置下Contiki只占用約2Kbytes的RAM以及40Kbytes的Flash存儲器。Contiki中還包括一個可選的GUI子系統，可以提供對本地串口終端、基于VNC的網絡化虛擬顯示或者Telnet的圖形化支持。

Contiki進程的阻塞是建立在“函數返回”的基礎上的，如上圖所示，當進程調用PROCESS_YIELD（）本質就是return，它向ContikiOS讓出系統控制權。

當進程需要處理更復雜的邏輯時，如果把所有的阻塞語句“裹挾”在進程主體函數時，就會帶來如下問題：主體函數會很冗長，并且很復雜。這違背軟件開發的精髓----降低程序的復雜度。

以uc/os-ii為代表的RTOS對于任務阻塞（一般使用等待：信號量、郵箱、消息隊列等）是很輕松的，這種基于“上下文切換”（Context Switch）的系統，可以在任務調用的任意函數語句中“掛起自己”，如上圖所示。

其實Contiki進程可以調用protothread實現“函數級阻塞”，如上圖所示：

①當protothread等待事件時，它先向process調用PT_YIELD（）“掛起函數”；process收到protothread的PT_YIELDED返回值時，執行PROCESS_YIELD（）“掛起進程”，向ContikiOS讓出系統控制權。

②當外部事件（一般為中斷）向ContikiOS發消息時，ContikiOS先調度對應的process，process則繼續調用protothread，protothread再處理該事件。

③當protothread處理完所有邏輯后，它向process返回PT_ENDED，此時process知道該protothread已經完成工作。

通過這種“函數級阻塞”技術，可以將邏輯復雜的進程分解成多個protothread，采用分而冶之的辦法，讓程序設計和維護代價大大降低。

小結：Contiki系統調度和阻塞實質是“函數返回”，因此進程設計有3條原則：

① 每個進程響應一個硬件的poll消息；

② 多個硬件之間的時序交給ISR用狀態機完成；

③ 進程主體函數盡可能簡單，如果復雜將拆分成多個protothread。