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。