2026-09-22

电机控制与 RTOS 的职责划分:保留中断电控,改善 Agent 交互

架构讨论备份:保留PWM触发ADC及中断电控链路,用RTOS组织通信与外围业务,并明确Agent命令和实验状态语义。

记录日期:2026-09-22。本文是架构讨论备份,尚未实施 RTOS 迁移,也不是实时性验收报告。

核心决定:严格保留 PWM 触发 ADC、ADC 转换完成触发中断、电控算法在中断中执行的链路。RTOS 用于组织通信、实验请求和记录等外围业务,不承接电机关键电控算法。

为什么考虑 RTOS

随着串口工作台、Agent 交互、波形传输和数据记录增加,单一前台状态机会逐渐承担更多等待、恢复与调度逻辑。RTOS 可以让这些业务分别等待事件,明确各模块的执行上下文和资源所有权。

采用 RTOS 的目的,是改善外围业务的长期维护性。Agent 交互是否可靠,则取决于协议和操作语义是否清晰;引入 RTOS 本身不会自动解决这一问题。

实时控制链路保持独立

1
2
3
4
5
6
7
PWM 定时器事件
ADC 硬件采样与转换
ADC 中断:采样处理 → 电控算法 → PWM 更新 → 快速保护
完整采样组末尾:执行简短、有界的控制请求

通信、显示和存储不能阻塞该链路。控制中断不等待任务、不获取任务互斥锁,也不承担串口解析、日志格式化或文件写入。

若采用 FreeRTOS,需要根据 Cortex-M 端口配置中断优先级。高于内核允许调用 API 的优先级范围的中断,不能调用 RTOS API,包括 FromISR 接口。可让电控中断保持在此范围,通过独立的邮箱和快照与任务交接。仍需审核全局关中断、Flash 操作、共享总线及实际执行时序,不能仅凭优先级配置宣称实时性已经得到保证。

建议的初始任务划分

执行位置职责
ADC 控制中断采样、电控算法、PWM 更新、快速保护;维护实时控制状态
控制服务任务唯一的命令提交者;管理外部实验请求、操作编号及进度,向中断提交有界请求
通信任务收发、协议解析、去重、状态事件和波形传输
后续按需增加的存储任务保存记录、管理写入和错误恢复

关键电控状态机及依赖采样节拍的实验动作仍留在实时侧。控制服务任务管理的是请求和结果,不按任务调度节拍生成 PWM 或执行电流环。

任务数量先保持少而明确。多个任务不能直接修改同一份电机控制状态;优先让一个控制服务任务统一向中断提交请求。

当前单槽邮箱如何衔接

讨论时的实现是裸机前台与 ADC 中断之间的单槽交接:前台构造请求,发布参数指针和回调,在完整采样组结束时由中断执行,写回结果后清空槽位。前台同步等待,因此请求对象在执行期间一直有效。

现有邮箱不能直接当成多任务消息队列使用。迁移时需处理:

具体等待机制、超时和队列容量尚未选定,需要在实现时按时序要求决定。

让串口更适合 Agent

当前协议已有请求编号、CRC 和固件身份检查。后续重点是补齐操作语义:

能力目的
区分已接受与已完成START 成功应答只表示启动获准,不表示定位或辨识已经成功
为实验分配操作编号可查询进度、终态、结果和中止原因
主动报告状态变化明确定位、稳定等待、注入、完成、失败等阶段,减少猜测和无效轮询
返回具体拒绝原因区分忙碌、参考无效、故障未复归和参数越界
定义重试与去重语义同一请求重发不会重复执行 START;重连后的处理规则也要明确
查询能力与实际配置提供支持的命令、单位、范围、固件身份和生效参数
单一控制权网页与 Agent 明确交接操作权;保护和紧急停止不依赖控制权持有者在线

建议优先实现一条完整的操作链:

1
2
3
提交实验请求 → 已接受(操作编号) → 执行中 → 完成 / 中止 / 失败
                              可查询状态与原因

波形数据与命令应答需要合理调度,避免大批量数据传输拖延控制请求处理。可靠保护条件,例如持续限幅达到规定时长后的退出,应由板端执行;不能依赖 Agent 轮询、电脑调度和串口往返来保证时限。

实施顺序与验证边界

先明确命令、操作状态、失败原因和所有权,再建立通信任务与唯一控制服务任务,适配邮箱和请求生命周期。整个过程保留现有电控中断链路。

随后检查通信高负载、波形传输、重试、断连和存储期间的控制中断时序,并验证停止及故障处理。没有经过这些测量,不能将“已使用 RTOS”或“电控中断优先级最高”当作实时性通过的证据。

本次记录只确定架构方向:长期以 RTOS 组织外围业务,以严格硬件触发的中断链路执行关键电控。协议细节和迁移实现另行设计。