记录日期:2026-09-22。本文是架构讨论备份,尚未实施 RTOS 迁移,也不是实时性验收报告。
核心决定:严格保留 PWM 触发 ADC、ADC 转换完成触发中断、电控算法在中断中执行的链路。RTOS 用于组织通信、实验请求和记录等外围业务,不承接电机关键电控算法。
为什么考虑 RTOS
随着串口工作台、Agent 交互、波形传输和数据记录增加,单一前台状态机会逐渐承担更多等待、恢复与调度逻辑。RTOS 可以让这些业务分别等待事件,明确各模块的执行上下文和资源所有权。
采用 RTOS 的目的,是改善外围业务的长期维护性。Agent 交互是否可靠,则取决于协议和操作语义是否清晰;引入 RTOS 本身不会自动解决这一问题。
实时控制链路保持独立
| |
通信、显示和存储不能阻塞该链路。控制中断不等待任务、不获取任务互斥锁,也不承担串口解析、日志格式化或文件写入。
若采用 FreeRTOS,需要根据 Cortex-M 端口配置中断优先级。高于内核允许调用 API 的优先级范围的中断,不能调用 RTOS API,包括 FromISR 接口。可让电控中断保持在此范围,通过独立的邮箱和快照与任务交接。仍需审核全局关中断、Flash 操作、共享总线及实际执行时序,不能仅凭优先级配置宣称实时性已经得到保证。
建议的初始任务划分
| 执行位置 | 职责 |
|---|---|
| ADC 控制中断 | 采样、电控算法、PWM 更新、快速保护;维护实时控制状态 |
| 控制服务任务 | 唯一的命令提交者;管理外部实验请求、操作编号及进度,向中断提交有界请求 |
| 通信任务 | 收发、协议解析、去重、状态事件和波形传输 |
| 后续按需增加的存储任务 | 保存记录、管理写入和错误恢复 |
关键电控状态机及依赖采样节拍的实验动作仍留在实时侧。控制服务任务管理的是请求和结果,不按任务调度节拍生成 PWM 或执行电流环。
任务数量先保持少而明确。多个任务不能直接修改同一份电机控制状态;优先让一个控制服务任务统一向中断提交请求。
当前单槽邮箱如何衔接
讨论时的实现是裸机前台与 ADC 中断之间的单槽交接:前台构造请求,发布参数指针和回调,在完整采样组结束时由中断执行,写回结果后清空槽位。前台同步等待,因此请求对象在执行期间一直有效。
现有邮箱不能直接当成多任务消息队列使用。迁移时需处理:
- 保持单一提交者,或在任务侧串行化请求,避免多个任务竞争空槽。
- 将前台忙等改成适合任务的完成等待;若控制中断不能调用 RTOS API,可由允许调用 API 的交接上下文转发完成事件。
- 明确请求对象生命周期。任务超时不能直接销毁中断尚可能引用的对象。
- 保留停止代次校验:停机后,旧 START 请求不得重新使能。
- 明确 STOP 的路径与时限。软件停止请求不能替代板端独立保护。
具体等待机制、超时和队列容量尚未选定,需要在实现时按时序要求决定。
让串口更适合 Agent
当前协议已有请求编号、CRC 和固件身份检查。后续重点是补齐操作语义:
| 能力 | 目的 |
|---|---|
| 区分已接受与已完成 | START 成功应答只表示启动获准,不表示定位或辨识已经成功 |
| 为实验分配操作编号 | 可查询进度、终态、结果和中止原因 |
| 主动报告状态变化 | 明确定位、稳定等待、注入、完成、失败等阶段,减少猜测和无效轮询 |
| 返回具体拒绝原因 | 区分忙碌、参考无效、故障未复归和参数越界 |
| 定义重试与去重语义 | 同一请求重发不会重复执行 START;重连后的处理规则也要明确 |
| 查询能力与实际配置 | 提供支持的命令、单位、范围、固件身份和生效参数 |
| 单一控制权 | 网页与 Agent 明确交接操作权;保护和紧急停止不依赖控制权持有者在线 |
建议优先实现一条完整的操作链:
| |
波形数据与命令应答需要合理调度,避免大批量数据传输拖延控制请求处理。可靠保护条件,例如持续限幅达到规定时长后的退出,应由板端执行;不能依赖 Agent 轮询、电脑调度和串口往返来保证时限。
实施顺序与验证边界
先明确命令、操作状态、失败原因和所有权,再建立通信任务与唯一控制服务任务,适配邮箱和请求生命周期。整个过程保留现有电控中断链路。
随后检查通信高负载、波形传输、重试、断连和存储期间的控制中断时序,并验证停止及故障处理。没有经过这些测量,不能将“已使用 RTOS”或“电控中断优先级最高”当作实时性通过的证据。
本次记录只确定架构方向:长期以 RTOS 组织外围业务,以严格硬件触发的中断链路执行关键电控。协议细节和迁移实现另行设计。