第1章：RTOS任务创建——实时任务优先级设计、任务栈大小估算、任务间通信机制选择
各位同学，咱们今天聊点实在的。RTOS任务创建，说白了就是给实时系统搭骨架。骨架搭不好，后面跑起来全是坑。我这些年调试过的EtherCAT主站，十有八九的问题都出在任务设计上。
1.1 实时任务优先级设计
优先级设计，是RTOS里最容易被低估的环节。很多人觉得“优先级嘛，数字大的先跑呗”，结果一上系统就崩。
核心原则：
- 硬实时任务（比如EtherCAT周期数据收发）必须最高优先级
- 软实时任务（比如状态机处理）次之
- 非实时任务（比如日志打印、用户界面）放最低
我个人习惯把优先级分成三层：
| 层级 | 典型任务 | 优先级范围 | 说明 |
|---|---|---|---|
| 高 | EtherCAT DC同步、伺服控制 | 80-99 | 抢占所有其他任务 |
| 中 | 协议解析、状态机 | 40-79 | 可被高优先级打断 |
| 低 | 日志、诊断、配置 | 1-39 | 空闲时执行 |
为什么会这样？因为RTOS调度器在相同优先级下，默认是时间片轮转。但EtherCAT这种对抖动敏感的场景，时间片轮转会导致周期抖动。你想想看，一个1ms周期的控制任务，被另一个同优先级任务抢走500μs，这控制精度还能看吗？
1.2 任务栈大小估算
栈大小估算，是新手最容易翻车的地方。我见过有人直接给每个任务分配4KB，结果跑起来栈溢出，系统随机死机。查了三天，最后发现是栈不够。
估算方法：
- 静态分析： 数一下函数调用深度，每个函数局部变量大小，加上中断嵌套深度
- 动态测量： 在任务入口和出口打印栈指针差值，跑典型工况
- 留余量： 实测值 × 1.5 ~ 2.0
实战经验： 我一般这样估算EtherCAT主站任务的栈：
- EtherCAT周期任务：4KB（含中断嵌套）
- 协议解析任务：2KB
- 日志任务：1KB
但注意，这只是起步值。实际跑起来要用工具监控栈使用峰值。
// 示例：FreeRTOS任务创建时指定栈大小
// 单位是字（word），32位系统一个字=4字节
#define ECAT_TASK_STACK_SIZE 1024 // 4KB
#define PARSER_TASK_STACK_SIZE 512 // 2KB
#define LOG_TASK_STACK_SIZE 256 // 1KB
xTaskCreate(
ecat_task, // 任务函数
"EtherCAT", // 任务名
ECAT_TASK_STACK_SIZE, // 栈大小（字）
NULL, // 参数
90, // 优先级
NULL // 任务句柄
);
1.3 任务间通信机制选择
任务间通信，说白了就是让不同优先级的任务能安全地交换数据。EtherCAT主站里，高频任务（比如周期收发）和低频任务（比如状态机）之间怎么传数据？
常见机制对比：
| 机制 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 消息队列 | 异步数据传递 | 解耦好，支持多生产者/消费者 | 有拷贝开销 |
| 信号量 | 事件通知 | 轻量，快速 | 不能传数据 |
| 共享内存+互斥锁 | 大数据块共享 | 零拷贝 | 容易死锁 |
| 邮箱 | 小数据同步 | 简单直接 | 阻塞调用 |
我个人习惯这样选：
- EtherCAT帧数据：用共享内存+无锁环形缓冲区。因为数据量大，拷贝一次就几百微秒，受不了。
- 状态变化通知：用信号量。比如从机断开了，发个信号量让状态机去处理。
- 调试命令：用消息队列。因为命令频率低，而且需要排队处理。
你想想看，EtherCAT周期是1ms，如果每次通信都加锁解锁，那开销就大了。所以高频路径上，我倾向于用无锁设计。比如用DMA双缓冲，一个缓冲区给硬件写，一个给任务读，交替使用。
1.4 实战：EtherCAT主站任务架构
最后，我画一张图，把上面这些串起来。这是我在一个实际项目中用过的架构：
这张图里，数据从硬件层上来，高优先级任务用无锁环形缓冲区直接拿，不阻塞。处理完后，通过消息队列丢给中优先级任务做协议解析。中优先级任务发现异常，用信号量通知低优先级任务去记录日志。这样，每个任务各司其职，优先级高的不会被优先级低的拖累。
好了，这一章的内容就到这里。记住：优先级设计要分层，栈大小要实测加余量，通信机制要按场景选。下一章咱们聊EtherCAT的DC同步机制，那个更刺激。