3、Contiki系统架构：核心组件（内核、网络栈、文件系统、电源管理）、事件驱动模型与protothread机制

Contiki作为面向物联网场景的轻量级操作系统，其设计哲学与通用嵌入式RTOS（如FreeRTOS、uC/OS）有本质差异。它不追求完整的进程隔离和优先级抢占，而是以事件驱动为核心，配合protothread这种“伪线程”机制，在极低的内存开销下实现多任务并发。理解Contiki的系统架构，关键在于把握三个层次：底层核心组件如何组织硬件资源、中层事件驱动模型如何调度任务、上层protothread如何简化编程模型。本章将逐一拆解这些机制，并结合实际代码和调试经验，帮助你建立对Contiki运行时的整体认知。

上图展示了Contiki系统的整体架构分层。从下至上依次为硬件抽象层、核心组件层、事件驱动模型层和Protothread机制层。硬件抽象层屏蔽了不同MCU的差异，核心组件提供基础服务，事件驱动模型负责任务调度，而Protothread则是在事件驱动之上构建的编程抽象。下面我们逐一深入每个模块。

3.1 内核：事件队列与进程调度器

核心原理：协作式多任务与事件循环

Contiki内核采用协作式多任务（Cooperative Multitasking）设计，这意味着任务不会被系统强制抢占，而是必须主动让出CPU。内核维护一个全局事件队列（Event Queue），所有系统事件（如定时器超时、网络数据到达、传感器中断）都被封装为事件结构体，按FIFO顺序排队。主循环不断从队列头部取出事件，调用对应的进程回调函数处理。这种设计避免了优先级反转和临界区保护问题，但要求每个进程的处理函数必须快速返回，不能阻塞。

内核的核心数据结构是struct process，每个进程包含一个线程函数指针、进程名称、事件处理状态等。调度器通过process_run()函数驱动事件分发，而process_post()用于向指定进程投递事件。值得注意的是，Contiki还提供process_poll()机制，用于处理高优先级事件（如硬件中断），它会在普通事件之前被检查。

操作流程：事件驱动的标准生命周期

1. 初始化：调用process_init()初始化内核，注册所有静态进程。
2. 启动：调用process_start()启动自动启动的进程。
3. 主循环：在while(1)中调用process_run()处理事件，然后调用etimer_process()检查定时器，最后进入低功耗模式（可选）。
4. 事件投递：任何代码（包括中断服务程序）可通过process_post()向特定进程发送事件。
5. 事件处理：进程回调函数被调用，执行相应逻辑，然后返回等待下一个事件。

// 定义一个进程
PROCESS(my_process, "My Process");
PROCESS_THREAD(my_process, ev, data)
{
  PROCESS_BEGIN();
  while(1) {
    PROCESS_WAIT_EVENT(); // 等待事件
    if(ev == my_custom_event) {
      // 处理自定义事件
      printf("Event received!\n");
    }
  }
  PROCESS_END();
}

// 在其他地方投递事件
process_post(&my_process, my_custom_event, NULL);

案例拆解：传感器数据采集与上报

假设我们需要周期性地读取温度传感器并通过无线发送。传统RTOS会创建两个线程：一个负责定时采集，一个负责网络发送。在Contiki中，我们只需一个进程，利用etimer定时器触发事件，在事件处理中完成采集和发送。整个过程无需线程切换，内存占用仅为一个进程控制块（约几十字节）。

常见误区与总结

总结：内核的事件驱动模型是Contiki低内存占用的基石。理解“协作式”意味着每个进程必须自律，这是编写Contiki应用的第一原则。

3.2 网络栈：uIP与Rime协议体系

核心原理：分层协议与零拷贝设计

Contiki网络栈分为两层：uIP（Micro IP）提供标准TCP/IPv4/IPv6支持，Rime是专为传感器网络设计的轻量级协议栈。uIP采用“单缓冲区”设计，整个协议栈共享一个全局数据包缓冲区（uip_buf），各层协议通过指针操作修改数据，避免数据拷贝。Rime则提供更底层的广播、单播、可靠传输等原语，适合低功耗无线网络。

网络栈的事件驱动体现在：当无线收发器接收到数据包时，产生硬件中断，中断服务程序将数据放入缓冲区，并投递一个tcpip_event事件。uIP进程被唤醒后，从缓冲区解析数据，根据协议类型调用相应的应用回调（如HTTP服务器回调）。

操作流程：数据包接收与发送

1. 接收路径：无线驱动 → 中断 → 数据放入uip_buf → 投递事件 → uIP进程处理 → 应用回调。
2. 发送路径：应用调用uip_udp_packet_send() → 数据写入uip_buf → 协议栈填充头部 → 调用MAC层发送函数 → 无线驱动发送。

案例拆解：IPv6 over 6LoWPAN 数据上报

在典型的物联网场景中，节点通过6LoWPAN接入边界路由器。Contiki的contiki-main.c中会初始化网络接口，启动tcpip_process。应用层使用UDP socket发送数据。关键配置包括：

#define UIP_CONF_IPV6 1
#define UIP_CONF_ROUTER 0
#define UIP_CONF_BUFFER_SIZE 256
#define UIP_CONF_UDP 1
#define UIP_CONF_TCP 0

发送数据时，应用调用uip_udp_packet_sendto()，该函数会构造UDP头、IPv6头，然后通过6LoWPAN压缩层进行头部压缩，最后交给IEEE 802.15.4 MAC层发送。整个过程在事件驱动下完成，无需阻塞等待。

常见误区与总结

总结：网络栈的设计目标是“够用就好”，在资源受限环境下提供必要的网络功能。理解单缓冲区模型有助于避免内存拷贝带来的性能问题。

3.3 文件系统与电源管理

核心原理：Coffee文件系统与LPM电源管理

Coffee是Contiki为NOR Flash设计的日志型文件系统。它采用追加写入（Append-only）策略，每次修改数据都写入新位置，避免擦除操作。Coffee支持文件创建、读取、追加和删除，但不支持随机写入。其设计目标是提供简单的配置存储和日志记录功能，而非通用文件系统。

电源管理由lpm.c实现，它根据系统状态自动切换MCU的休眠模式。当事件队列为空且没有定时器即将超时时，系统进入低功耗模式（如AVR的IDLE或SLEEP模式）。LPM模块还提供lpm_register()接口，允许外设驱动注册唤醒源。

操作流程：Coffee文件读写与电源状态切换

1. 文件写入：cfs_open()打开文件 → cfs_write()追加数据 → cfs_close()关闭。数据先写入RAM缓冲，再批量刷入Flash。
2. 电源切换：主循环检测到无事件 → 调用lpm_enter() → MCU进入休眠 → 外部中断或定时器唤醒 → lpm_exit()恢复。

#include "cfs/cfs.h"
#define CALIB_FILE "calib.dat"

void save_calibration(int offset) {
  int fd = cfs_open(CALIB_FILE, CFS_WRITE);
  if(fd != -1) {
    cfs_write(fd, &offset, sizeof(offset));
    cfs_close(fd);
  }
}

int load_calibration(void) {
  int offset = 0;
  int fd = cfs_open(CALIB_FILE, CFS_READ);
  if(fd != -1) {
    cfs_read(fd, &offset, sizeof(offset));
    cfs_close(fd);
  }
  return offset;
}

案例拆解：低功耗无线传感器节点设计

设计一个电池供电的温湿度传感器节点，要求平均功耗低于50µA。实现方案：

• 使用etimer设置60秒周期唤醒。
• 在事件处理中完成传感器读取、数据发送。
• 发送完成后立即进入休眠。
• 使用Coffee存储节点ID和网络配置。

实际测试数据：休眠电流2µA（MCU SLEEP模式），唤醒后工作电流15mA（持续20ms），平均功耗计算：(15mA * 0.02s + 2µA * 59.98s) / 60s ≈ 5µA。这得益于事件驱动模型和LPM的紧密配合。

常见误区与总结

总结：Coffee和LPM是Contiki面向低功耗物联网场景的重要组件。合理使用它们，可以显著延长电池寿命。

3.4 Protothread机制：轻量级线程的实现艺术

核心原理：基于C宏的协程实现

Protothread是Contiki最具特色的机制。它利用C语言的switch-case和__LINE__宏，在函数内实现类似线程的阻塞语义。每个protothread是一个C函数，通过PT_BEGIN()和PT_END()包裹，内部使用PT_WAIT_UNTIL(cond)实现条件等待。当条件不满足时，函数保存当前行号并返回；下次调用时，通过switch跳转到上次保存的行号继续执行。

这种设计的精妙之处在于：不需要独立的栈，所有局部变量必须声明为static或使用PT_YIELD机制。每个protothread仅占用一个struct pt结构体（包含一个unsigned short类型的行号），内存开销极小。

操作流程：编写一个protothread

1. 定义static struct pt pt;作为线程控制块。
2. 编写线程函数，使用PT_BEGIN(&pt)开始。
3. 使用PT_WAIT_UNTIL(&pt, condition)等待条件。
4. 使用PT_YIELD(&pt)主动让出CPU。
5. 使用PT_END(&pt)结束。

static struct pt led_pt;
static int led_state;

static int led_thread(struct pt *pt) {
  PT_BEGIN(pt);
  while(1) {
    led_state = !led_state;
    LED_PORT = led_state;
    PT_WAIT_UNTIL(pt, etimer_expired(&led_timer));
    etimer_reset(&led_timer);
  }
  PT_END(pt);
}

案例拆解：多传感器轮询调度

假设需要同时轮询3个传感器，每个传感器读取需要等待不同时间。使用protothread可以优雅地实现并发等待：

static struct pt sensor_pt[3];
static int sensor_value[3];

static int sensor_thread(struct pt *pt, int sensor_id) {
  PT_BEGIN(pt);
  while(1) {
    sensor_value[sensor_id] = read_sensor(sensor_id);
    PT_WAIT_UNTIL(pt, etimer_expired(&sensor_timer[sensor_id]));
    etimer_reset(&sensor_timer[sensor_id]);
  }
  PT_END(pt);
}

在main中，通过PT_SPAWN或手动调用三个线程函数，实现“伪并发”。实际上，它们共享同一个栈，但通过行号保存和恢复执行点。

常见误区与总结

总结：Protothread是Contiki在“极简内存”和“编程便利性”之间的巧妙折中。它适合IO密集型的物联网应用，但不适合CPU密集型计算。理解其宏展开原理，有助于编写健壮的代码。