一、引言

在嵌入式系统开发中，通信协议不仅需要完成数据收发，还需要与设备控制、数据采集、状态管理等功能协同运行。

Modbus RTU 是工业自动化领域常见的串行通信协议，具有帧格式明确、实现方式成熟、便于设备互联等特点。在智能仪表、工业控制器、传感器节点和数据采集终端中，都可以看到它的应用。

对于经典及增强型 8051 单片机，开发者通常需要自行组织 UART 中断、接收缓冲区、帧间隔检测、CRC 校验、功能码处理和响应发送。当应用功能逐渐增加时，如何管理这些不同的执行流程，便成为软件架构设计中的一个重要问题。

HRTOS 是一款专注于 8051 平台的实时操作系统。除了内核调度功能，项目还配套建设驱动、Shell、通信组件、示例工程及技术文档。Modbus RTU 从站模块则是操作系统能力与具体嵌入式通信应用结合的一个实例。

本文从系统架构和工程集成的角度，介绍 HRTOS Modbus RTU 模块的基本设计思路。

二、为什么要将通信协议与 RTOS 结合？

传统裸机程序经常采用主循环轮询方式组织功能，例如：

• 检查 UART 接收状态；

• 判断一帧数据是否接收完成；

• 校验报文并解析功能码；

• 更新设备参数；

• 发送响应；

• 执行其他控制逻辑。

当程序规模较小时，这种方式具有实现直接的优点。但当串口通信与周期采样、设备控制、告警处理等功能同时存在时，主循环可能逐渐承担过多职责，程序状态也会变得复杂。

引入实时操作系统后，可以按照功能职责划分任务，并通过事件等机制协调任务之间的工作。

在 HRTOS Modbus RTU 模块中，UART 数据接收、帧超时检测和协议处理被组织为不同的执行入口。串口接收侧负责获取数据，帧检测任务负责判断当前接收帧的状态，协议处理任务则负责后续解析与响应。

需要注意，RTOS 并不会自动保证通信协议的正确性。协议格式检查、缓冲区边界、帧间隔精度和异常请求处理，仍然需要由模块实现与测试来保证。

三、HRTOS Modbus RTU 模块的功能组成

当前模块面向 8051 单片机实现 Modbus RTU 从站处理，主要包括以下部分：

当前源码实现了五种常用功能码：

默认配置下，从站地址为 1，保持寄存器数量为 32，线圈数量为 8。具体参数可根据目标设备的存储资源和业务需求进行调整。

四、软件架构与数据处理流程

HRTOS Modbus RTU 模块采用分层设计，将协议逻辑与底层 UART 适配分离。

整体数据流程如下：

              UART 接收中断
                    |
                    v
              接收字节处理
                    |
                    v
                接收缓冲区
                    |
                    v
             帧超时检测任务
                    |
                    v
             HRTOS 事件通知
                    |
                    v
              Modbus 处理任务
                    |
                    v
             帧解析与 CRC 校验
                    |
                    v
               从站功能处理
                    |
                    v
             寄存器或线圈访问
                    |
                    v
                生成响应帧
                    |
                    v
                 UART 发送

这种设计将接收过程和协议处理过程分离，减少了不同职责之间的直接耦合。

在应用层，开发者可以通过寄存器和线圈接口访问通信数据，而不必在业务逻辑中重复实现整个 Modbus RTU 帧解析流程。

例如，设备可以将测量结果映射到保持寄存器，将运行状态映射到线圈，再由主站通过相应功能码读取数据。对于允许远程修改的参数，也可以在写寄存器接口中增加应用层范围检查、权限判断和参数生效逻辑。

五、任务与事件机制的作用

当前示例工程通过三个任务入口组织相关工作：

以上为当前示例工程中的配置，具体任务创建参数应以实际工程代码和 HRTOS API 定义为准。

其中，事件机制用于将帧检测与协议处理连接起来。当帧检测逻辑判断当前接收过程达到设定阈值后，便通知协议处理任务继续执行。

这种组织方式有助于让协议处理任务在没有待处理帧时等待事件，而不是持续执行完整的协议解析流程。

不过，当前模块的帧结束检测采用周期任务和计数阈值实现，并非直接通过硬件定时器精确测量 Modbus RTU 所要求的 3.5 字符时间。因此，对于需要严格满足串行通信时序的实际产品，应结合波特率、任务调度误差及硬件定时能力进一步完善帧间隔检测。

六、寄存器映射与应用集成

寄存器映射是 Modbus 从站与具体设备业务之间的重要接口。

当前模块提供保持寄存器与线圈的读写函数。默认配置包含 32 个保持寄存器和 8 个线圈，开发者可以围绕这些接口构建设备的数据模型。

例如，可以将寄存器规划为：

这只是应用层规划示例，实际地址定义需要结合设备协议自行制定。

在工程设计中，还应考虑寄存器读写与后台任务之间的数据一致性。对于会被多个任务同时访问的数据，应根据访问方式设计必要的同步机制，避免出现读写竞争或中间状态被其他任务观察到的问题。

此外，协议层接受写请求，并不意味着相关参数一定可以直接生效。涉及电机控制、继电器输出或其他具有风险的控制操作时，仍应由应用层执行范围检查、状态判断和必要的安全联锁。

七、工程移植与验证要点

将 Modbus RTU 模块移植到不同 8051 单片机时，需要重点检查以下内容。

1. UART 与波特率配置

底层串口初始化应根据 MCU 型号、晶振频率和 UART 时钟配置重新计算波特率。不能简单复制其他工程中的定时器重装值。

2. 接收与发送路径

需要确认 UART 接收中断能够正确读取数据，并按目标芯片的要求处理相关中断标志。当前发送路径采用逐字节阻塞发送，应评估其对任务执行时间和通信时序的影响。

3. 缓冲区与报文长度

接收缓存和发送缓存应覆盖目标应用需要的报文长度。当前默认发送缓存为 32 字节，在读取保持寄存器时，应将完整响应长度纳入检查，避免超出缓冲区容量。

4. 异常请求处理

应补充并验证功能码对应的数据长度检查、非法地址、非法数量、CRC 错误及不完整报文等情况，避免对尚未接收的数据进行访问。

5. 广播请求

Modbus RTU 地址 0 用于广播。广播请求的处理应遵守相应协议规则，不应像普通单播请求一样返回正常响应。

6. 连续请求与长时间运行

需要验证连续请求、异常帧插入、接收缓存边界和事件处理之间的时序关系，并通过实际串口测试与长时间运行测试检查可靠性。

这些检查既是协议模块移植的一部分，也是将示例代码用于实际设备之前需要完成的工程工作。

八、从通信组件看 HRTOS 的系统化建设

对于嵌入式操作系统而言，内核调度只是整个软件体系的基础。开发者在实际项目中，还需要驱动接口、通信模块、调试工具、示例工程和文档来完成从内核能力到应用功能的集成。

HRTOS 围绕 8051 平台持续建设相关内容，包括：

• 实时内核及任务管理；

• 任务同步与消息通信机制；

• Shell 命令交互与系统调试；

• Modbus RTU 通信组件；

• 外设驱动与示例工程；

• 系统手册、API 参考和使用说明。

这种建设思路强调专用平台上的系统完整性。相比只关注内核本身，完整的开发资源能够帮助使用者更好地理解接口、组织应用程序并定位工程问题。

HRTOS 坚持专注 8051，不以支持更多处理器架构作为主要目标，而是围绕 8051 的执行模型、中断机制、存储结构和开发工具链持续完善系统能力。

九、总结

HRTOS Modbus RTU 模块展示了实时操作系统与工业通信协议结合的一种实现方式。通过任务、事件、帧处理、CRC 校验和寄存器管理等模块，通信逻辑可以按照相对清晰的职责进行组织，并进一步与设备控制和数据采集功能集成。

当前模块仍需要针对协议边界和异常请求处理进行完善，正式应用前应完成必要的修正与测试。它更适合作为 HRTOS 通信功能的集成基础，而不是未经验证即可直接用于所有工业设备的完整协议产品。

HRTOS 的长期方向，是围绕 8051 构建具有实时内核、系统组件、驱动、文档和示例支撑的完整开发体系，为经典与增强型 8051 单片机应用提供持续维护的软件基础。

HRTOS：专注 8051，完善系统能力，坚持长期维护。