企业官网建设流程全解析

1. 项目背景与核心价值：为什么在ESP32上跑CANopen不是“炫技”，而是工程刚需

CANopen协议栈移植到ESP32，这个标题背后藏着的不是一句简单的技术复述，而是一条从工业现场真实痛点里长出来的技术路径。我第一次接到客户需求时，对方拿着一台老旧的伺服驱动器和一台刚采购的ESP32-C3开发板，说：“我们要用WiFi把这台设备接入云平台，但驱动器只认CANopen PDO，不支持Modbus TCP，更别说HTTP了。”——那一刻我就知道，这不是在玩嵌入式玩具，而是在给产线做“神经接口手术”。

CANopen不是新东西，它诞生于上世纪90年代，是基于CAN总线的高层通信协议，被广泛用于运动控制、PLC互联、医疗设备、电梯系统等对实时性、确定性和互操作性要求极高的场景。它的核心优势在于标准化对象字典（Object Dictionary）、预定义连接集（PDO/SDO/NMT）和状态机管理（NMT State Machine），这些设计让不同厂商的设备能像“说同一种方言”一样互相理解。而ESP32，特别是ESP32-S2/S3/C3系列，凭借双核处理能力、丰富的外设（尤其是内置CAN控制器的ESP32-S2/S3）、低功耗特性和成熟的WiFi/BLE双模能力，正成为工业边缘网关、智能传感器节点、分布式IO模块的理想载体。把CANopen“种”进ESP32，本质是让低成本、高集成度的Wi-Fi MCU，具备了与传统工业设备“平起平坐”的对话资格。

你可能会问：直接用STM32或NXP的专用CAN MCU不行吗？当然行，但代价是：你需要额外加WiFi模块、写AT指令、处理串口透传、调试网络异常重连……整个系统变成“MCU+WiFi芯片+CAN收发器”三颗芯片的拼凑体，BOM成本、PCB面积、固件维护复杂度都翻倍。而ESP32单芯片搞定CAN物理层（通过外接TJA1050/TJA1042）、CAN协议解析、TCP/IP协议栈、MQTT/HTTP云对接，甚至带OLED显示和按键交互——这才是现代工业物联网的“极简主义”。标题里那个“(二)”，暗示这已是第二阶段，意味着第一阶段（基础CAN驱动验证、裸机CAN收发）已经跑通，现在要啃的是硬骨头：协议栈的完整移植、对象字典的工程化配置、状态机的鲁棒性保障、以及与ESP-IDF生态的无缝融合。这不是教科书里的Hello World，而是产线凌晨三点还在跑的固件版本。

关键词“esp32,canopen,can,协议栈”精准锁定了技术坐标系：硬件平台（ESP32系列）、通信介质（CAN总线）、协议规范（CANopen DS-301）、软件形态（可裁剪、可配置的协议栈）。而热搜词里混杂的“esp32 c5 功耗”、“j1939协议栈移植”、“ros 2 humble micro-ros esp32”，恰恰印证了这一方向的热度——工业界正在集体向ESP32迁移，而CANopen是绕不开的“工业母语”。至于那些“access error: 404”、“can not open com port”、“chatgpt can't load config.toml”的乱码式热词，不过是开发者在深夜调试失败时，浏览器崩溃、串口工具报错、IDE卡死的痛苦快照，它们无声地提醒我们：协议栈移植的坑，不在理论，而在每一个中断响应延迟、每一处内存对齐错误、每一次SDO块下载超时的细节里。

2. 整体架构设计与方案选型：为什么放弃“现成轮子”，选择深度定制CANopen协议栈

在动手写第一行代码前，我花了整整三天时间评估所有可能的方案。市面上确实有现成的CANopen协议栈，比如CANFestival（开源C库）、CANopenNode（MIT许可）、甚至商业版的CANopen Magic。但当我把它们丢进ESP-IDF v5.0的构建系统里，立刻暴露出三个致命问题：内存模型冲突、RTOS适配断裂、对象字典静态化僵硬。这让我彻底放弃了“拿来主义”，转而采用“核心复用+深度重构”的策略——即保留CANopen协议栈最精炼的逻辑内核（状态机、SDO/PDO编解码），但将其完全解耦为ESP-IDF原生组件，并用Kconfig进行模块化裁剪。

2.1 协议栈分层解耦：从“黑盒”到“乐高积木”

我把整个CANopen协议栈拆解为五个可独立编译、可按需启用的组件层：

1. CAN底层驱动层（can_driver）：这是与ESP-IDF HAL深度绑定的部分。它不直接调用driver/can.h的裸API，而是封装了一个can_bus_t句柄，提供can_bus_init()、can_bus_transmit()、can_bus_receive()三个原子接口。关键创新在于引入了环形缓冲区+任务通知（Task Notification）的接收机制：当CAN中断触发，硬件FIFO有数据时，驱动层将帧拷贝到RAM环形缓冲区，并通过xTaskNotifyGive()唤醒协议栈主任务。这避免了传统方案中频繁的xQueueSendFromISR()带来的队列阻塞风险，实测在1Mbps总线速率下，连续发送1000帧PDO，无一丢帧。

2. 协议核心引擎层（canopen_core）：这是协议栈的“心脏”，完全重写了CANFestival的状态机逻辑。它摒弃了全局静态变量的设计，改为每个CANopen节点实例（co_node_t）持有独立的对象字典指针、NMT状态、心跳计时器。最核心的改动是将NMT状态机从“宏定义状态跳转”改为“事件驱动状态机”：所有状态变更（如PRE-OPERATIONAL→OPERATIONAL）都由co_nmt_state_change_event()统一派发，上层应用只需注册回调函数即可响应，彻底解耦了协议逻辑与业务逻辑。

3. 对象字典管理层（od_manager）：这是工程化落地的关键。我放弃了传统协议栈中用#define硬编码OD条目的方式，转而设计了一套JSON Schema驱动的对象字典描述语言。工程师只需编写一个od_definition.json文件，例如：

   { "0x1000": {"name": "device_type", "type": "UINT32", "access": "ro", "value": 0x00000001}, "0x1018": {"name": "identity", "type": "RECORD", "subobjects": { "0": {"name": "max_subindex", "type": "UINT8", "value": 4}, "1": {"name": "vendor_id", "type": "UINT32", "value": 0x00001234}, "2": {"name": "product_code", "type": "UINT32", "value": 0x00005678} }} }

   编译时，一个Python脚本会解析此JSON，自动生成od_static.c和od_static.h，其中包含紧凑的结构体数组和高效的二分查找索引表。这样做的好处是：对象字典不再是“写死的代码”，而是“可配置的数据”，产线不同型号设备只需替换JSON文件，重新编译即可生成专属固件，OD条目增删改查零代码修改。

4. 应用服务层（app_services）：这是面向用户的“胶水层”。它封装了常用操作的便捷API，例如：

   • co_pdo_map_add(0x1A00, 0x2001, 0x00, 16)—— 将对象字典0x2001:00的16位数据映射到TPDO 0x1A00
   • co_sdo_download_async(0x1001, 0x00, &error_code, on_sdo_done_cb)—— 异步发起SDO下载，回调通知结果
   • co_heartbeat_start(1000)—— 启动1秒周期的心跳报文广播 这些API内部已处理了CAN ID计算、COB-ID掩码、传输超时重试等繁琐细节，用户调用时就像调用标准库函数一样自然。

5. ESP-IDF集成层（idf_integration）：这是让协议栈“活”在ESP-IDF生态里的最后一公里。它提供了CMakeLists.txt组件描述、Kconfig.projbuild配置项（如CONFIG_CANOPEN_ENABLE_PDO= y）、以及canopen_example示例工程。特别重要的是，它实现了FreeRTOS钩子函数注入：在vApplicationStackOverflowHook()中自动触发CANopen节点进入STOPPED状态并上报错误，避免栈溢出导致整个CAN网络瘫痪。

提示：选择深度定制而非直接移植，根本原因在于ESP-IDF的内存管理模型（Heap Malloc vs. Static Alloc）与传统嵌入式RTOS存在差异。强行套用旧协议栈，极易引发heap fragmentation（堆碎片）问题，尤其在频繁SDO块传输时。我们的方案强制所有协议栈内存（OD、PDO映射表、SDO传输缓冲区）在初始化时一次性malloc()分配，并通过CONFIG_CANOPEN_MEMORY_POOL_SIZE统一配置，杜绝了运行时内存不确定性。

2.2 硬件平台选型：为什么ESP32-S3是当前最优解

标题虽泛称“ESP32”，但实际工程中必须明确具体型号。我对比了ESP32-WROOM-32（无CAN）、ESP32-S2（无CAN）、ESP32-C3（单核CAN）、ESP32-S3（双核CAN）四款主流芯片：

最终选定ESP32-S3-DevKitC-1开发板，其双CAN控制器（CAN0/CAN1）允许我们构建“CAN主站+CAN从站”一体化设备：CAN0接PLC主站网络，CAN1接本地传感器子网，实现真正的边缘自治。实测在双核满载（Core0 95% CANopen负载，Core1 85% WiFi TLS加密负载）下，系统稳定运行超720小时无异常。而那些热搜词里反复出现的“esp32 c5 功耗”，恰恰说明行业对低功耗的极致追求——ESP32-S3的Ulp Coprocessor（超低功耗协处理器）可在主CPU休眠时，仅靠RTC内存维持CAN总线监听，功耗压至150μA，完美契合电池供电的远程IO节点需求。

3. 核心细节解析与实操要点：对象字典配置、PDO映射与NMT状态机的魔鬼细节

协议栈的骨架搭好后，真正的挑战藏在血肉之中。CANopen的威力与脆弱性，都源于其高度结构化的对象字典（Object Dictionary, OD）和严格的状态机（NMT State Machine）。很多开发者栽在第一步：OD配置看似简单，实则暗流涌动；PDO映射稍有偏差，数据就“发出去却收不到”；NMT状态跳变若未遵循时序，整个网络就会陷入“假死”。下面我将用真实调试日志和内存布局图，带你穿透这些细节。

3.1 对象字典（OD）：不只是数据表，更是设备的“宪法”

对象字典不是一堆变量的集合，它是CANopen设备的“宪法”，定义了设备能做什么、能被谁访问、以何种方式访问。OD条目（Object Entry）由索引（Index）、子索引（Sub-index）、数据类型（Data Type）、访问权限（Access）和值（Value）五部分构成。索引0x1000-0x1FFF是设备通用参数，0x2000-0x5FFF是厂商自定义区，0x6000-0x9FFF是过程数据（PDO相关），0xA000-0xFFFF是制造商特定区。

关键细节1：数据类型对齐与字节序陷阱
CANopen规定所有多字节数据（UINT16/INT32/FLOAT）必须采用Little-Endian（小端序）存储。但ESP32的CPU（Xtensa）也是小端，这看似省事，实则埋雷。问题出在结构体打包（Packing）上。例如，一个自定义结构体：

typedef struct { uint16_t status; // 0x2001:00 int32_t temp; // 0x2001:01 float humi; // 0x2001:02 } sensor_data_t;

如果未显式指定__attribute__((packed))，编译器会按4字节对齐插入填充字节，导致OD条目读取时数据错位。我在调试时发现，0x2001:01读出的温度值总是0x000000FF，就是因int32_t temp前被插入了2字节padding。解决方案：所有OD映射的结构体必须强制packed，并在OD定义JSON中明确标注"packing": "packed"，生成代码时自动添加属性。

关键细节2：只读（RO）条目的“伪写入”防御
OD中大量条目是RO（Read-Only），如0x1000 Device Type。但SDO客户端（如CANoe）仍可能尝试写入。协议栈必须对此类非法写入做出符合DS-301的响应：返回0x06010002（Object does not exist）错误码。然而，很多移植版本只是简单返回错误，却不记录日志。我在产线曾遇到PLC固件BUG，持续向0x1018 Identity子索引0（max_subindex）发送写请求，导致CAN总线被无效SDO淹没。因此，在od_manager层，我增加了非法访问审计日志：每次RO写入失败，都通过ESP_LOGW输出[OD] RO write to 0x1018:00 rejected，并统计1分钟内非法访问次数，超过阈值则触发NMT Error Control状态，强制节点进入PRE-OPERATIONAL，保护总线健康。

关键细节3：Record/Array类型条目的动态长度
0x1018 Identity是一个典型的Record类型条目，其子索引0（max_subindex）定义了该Record的实际长度。但很多协议栈将max_subindex硬编码为4，忽略了厂商可能扩展更多子索引。我们的方案在JSON定义中支持"dynamic": true标记，生成代码时，od_get_subindex_count()函数会动态查询0x1018:00的值，再遍历子索引，确保0x1018:05（如果存在）也能被正确访问。这为未来功能升级预留了空间。

3.2 PDO映射：让数据“飞”起来的精确制导系统

PDO（Process Data Object）是CANopen的“高速公路”，用于高速、低延迟的实时数据交换。TPDO（Transmit PDO）由本地设备发出，RPDO（Receive PDO）由本地设备接收。映射（Mapping）是指将OD中的具体条目（如0x2001:00）关联到PDO的某个字节偏移位置。这个过程极易出错。

实操要点1：COB-ID的计算逻辑
PDO的CAN ID（COB-ID）不是随意设定的，它由NMT节点ID和PDO类型共同决定。标准规则是：

• RPDO1:0x200 + node_id
• TPDO1:0x180 + node_id
• RPDO2:0x300 + node_id
• TPDO2:0x280 + node_id以此类推。注意，node_id是0x00-0x7F（127个节点），所以0x200 + 0x7F = 0x27F，仍在CAN 2.0B标准帧ID范围内（0x000-0x7FF）。我在调试时曾将node_id误设为0x80，导致RPDO1 COB-ID变为0x280，超出标准帧范围，CAN控制器拒绝发送。教训：node_id必须在Kconfig中强制校验范围。

实操要点2：PDO映射的“黄金三步法”
成功映射一个TPDO，必须严格按顺序执行三步（缺一不可）：

1. 配置映射参数（0x1A00-0x1A03）：写入0x1A00:00（number of entries）和0x1A00:01（first mapped object）等。这一步只是“告诉”节点“我要映射哪些东西”，不触发实际映射。
2. 写入映射条目（0x1600-0x1603）：将具体的OD索引/子索引/位长写入0x1600:01,0x1600:02等。这一步才是“填内容”。
3. 使能PDO（0x1800:01）：将0x1800:01（COB-ID）的bit0（Transmission Type）置1，PDO才真正激活。

我见过太多案例，开发者只做了第1步和第2步，忘了第3步，结果PDO“静默”——数据全在OD里，就是不发出去。调试时，用CAN分析仪抓包，看到0x1800:01的值是0x00000000（bit0=0），立刻就能定位。

实操要点3：同步模式下的“心跳”与“触发”
PDO有两种传输模式：Event-driven（事件驱动）和Synchronous（同步）。后者又分SYNC（由SYNC报文触发）和COS（Change of State）。新手常混淆0x1800:02（Inhibit Time）和0x1800:05（Event Timer）。前者是两次TPDO发送的最小间隔（微秒级），后者是COS模式下，状态变化后等待发送的定时器（毫秒级）。我在温湿度传感器项目中，将0x1800:02设为50000（50ms），确保10Hz采样率；将0x1800:05设为1000（1s），避免温度缓变时频繁发送。这些参数必须根据实际物理量变化率来定，而非拍脑袋。

3.3 NMT状态机：工业网络的“交通警察”

NMT（Network Management）状态机是CANopen网络的“大脑”，它定义了节点的生命周期：INITIALISING→PRE-OPERATIONAL→OPERATIONAL→STOPPED。状态跳变必须严格遵循DS-301，否则节点会被视为“离线”。

魔鬼细节1：PRE-OPERATIONAL的“静默期”
当节点上电，默认进入INITIALISING，然后自动跳到PRE-OPERATIONAL。此时，节点只响应NMT命令和SDO通信，不发送任何PDO。这是设计使然，目的是让主站有时间完成网络配置（如设置节点ID、PDO映射）。很多开发者在此阶段就急着发PDO，结果数据被主站忽略。正确做法是：在PRE-OPERATIONAL状态下，用SDO配置好所有PDO映射，再由主站发送NMT Start Remote Node (0x01)命令，节点才进入OPERATIONAL并开始PDO传输。

魔鬼细节2：心跳报文（Heartbeat）的生存证明
0x1017 Producer Heartbeat Time是心跳周期（毫秒）。节点进入OPERATIONAL后，会按此周期广播心跳报文（CAN ID =0x700 + node_id，数据为当前NMT状态）。主站监控此报文，若连续3个周期未收到，则判定节点故障。我在调试中发现，若0x1017设为0，心跳将被禁用，但节点仍处于OPERATIONAL——这看似正常，实则让主站失去故障检测能力。因此，在Kconfig中，我将CONFIG_CANOPEN_HEARTBEAT_TIME_MS默认设为1000，并强制>0。

魔鬼细节3：错误控制（Error Control）的自动降级
当节点发生严重错误（如OD访问越界、内存不足），协议栈应主动进入ERROR状态，并广播0x1001 Error Register。但DS-301规定，ERROR状态不能持久，必须在错误清除后，由主站发送NMT Reset Node (0x81)或NMT Reset Communication (0x82)命令恢复。我们的实现中，一旦检测到致命错误，立即调用co_nmt_enter_error_state()，并将错误码写入0x1001，同时停止所有PDO。这比“硬重启”更优雅，为主站提供了明确的故障诊断依据。

4. 实操过程与核心环节实现：从零开始构建一个可运行的CANopen从站节点

现在，让我们把前面所有理论付诸实践。以下是一个完整的、经过产线验证的ESP32-S3 CANopen从站节点构建流程，每一步都附有可直接复制的代码片段、配置说明和调试技巧。目标：让一个ESP32-S3开发板，作为节点ID=5的从站，通过CAN0接入主站网络，周期性发送温湿度数据（TPDO1），并响应主站的SDO读写请求。

4.1 环境准备与依赖安装：避开IDF版本陷阱

首先，确认你的开发环境。强烈建议使用ESP-IDF v5.1.4（截至2024年中最新LTS版本）。v5.0存在CAN驱动在高负载下的偶发丢帧问题，v5.2则因FreeRTOS更新引入了新的内存管理行为，与我们的协议栈内存池不兼容。安装步骤：

1. 下载ESP-IDF v5.1.4：git clone -b v5.1.4 --recursive https://github.com/espressif/esp-idf.git
2. 设置环境变量：export IDF_PATH=/path/to/esp-idf
3. 安装Python依赖：python -m pip install --user -r $IDF_PATH/requirements.txt
4. 关键一步：安装CAN收发器驱动。ESP32-S3的CAN控制器需要外接TJA1050（高速CAN）或MCP2562（兼容TJA1050）。在sdkconfig中，务必启用：

   CONFIG_CAN_ENABLED=y CONFIG_CAN_FRAMEWORK=y CONFIG_CAN_TSM_CONFIG=y CONFIG_CAN_TSM_MODE=0 # 0=Normal, 1=Loopback

注意：CONFIG_CAN_TSM_MODE=1（回环模式）仅用于纯软件测试，无法验证真实CAN波形。产线调试必须用MODE=0，并确保TJA1050的VCC、GND、CANH、CANL正确焊接，且CANH/CANL间跨接120Ω终端电阻（仅在总线两端）。

4.2 创建项目与协议栈集成：CMakeLists.txt的魔法

新建项目canopen_slave，目录结构如下：

canopen_slave/ ├── CMakeLists.txt # 项目根CMake ├── main/ │ ├── CMakeLists.txt # main组件CMake │ ├── app_main.c # 主程序入口 │ └── canopen_node.c # CANopen节点逻辑 ├── components/ │ └── canopen/ # 我们的协议栈组件 │ ├── CMakeLists.txt │ ├── Kconfig │ ├── canopen_core.c │ └── od_definition.json # 对象字典定义

根CMakeLists.txt（关键配置）：

cmake_minimum_required(VERSION 3.16) include($ENV{IDF_PATH}/tools/cmake/project.cmake) project(canopen_slave)

main/CMakeLists.txt（启用协议栈）：

set(COMPONENT_SRCS "app_main.c" "canopen_node.c") set(COMPONENT_ADD_INCLUDEDIRS ".") register_component() # 显式添加canopen组件依赖 target_link_libraries(${COMPONENT_TARGET} PRIVATE canopen)

components/canopen/CMakeLists.txt（协议栈构建）：

set(COMPONENT_SRCS "canopen_core.c" "od_manager.c" "can_driver.c" "idf_integration.c" ) set(COMPONENT_ADD_INCLUDEDIRS ".") # 自动生成OD代码 add_custom_target(generate_od COMMAND ${PYTHON} ${CMAKE_CURRENT_SOURCE_DIR}/scripts/gen_od.py ${CMAKE_CURRENT_SOURCE_DIR}/od_definition.json ${CMAKE_CURRENT_BINARY_DIR} DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/od_definition.json ) add_dependencies(${COMPONENT_TARGET} generate_od) register_component()

4.3 编写对象字典定义：od_definition.json实战

这是整个项目的“蓝图”。创建components/canopen/od_definition.json：

{ "0x1000": {"name": "device_type", "type": "UINT32", "access": "ro", "value": 0x00000001}, "0x1001": {"name": "error_register", "type": "UINT8", "access": "ro", "value": 0x00}, "0x1017": {"name": "producer_heartbeat_time", "type": "UINT16", "access": "rw", "value": 1000}, "0x1018": {"name": "identity", "type": "RECORD", "subobjects": { "0": {"name": "max_subindex", "type": "UINT8", "value": 4}, "1": {"name": "vendor_id", "type": "UINT32", "value": 0x00001234}, "2": {"name": "product_code", "type": "UINT32", "value": 0x00005678}, "3": {"name": "revision_number", "type": "UINT32", "value": 0x00000001}, "4": {"name": "serial_number", "type": "UINT32", "value": 0x0000ABCD} }}, "0x1800": {"name": "tpdo1_parameter", "type": "RECORD", "subobjects": { "0": {"name": "max_subindex", "type": "UINT8", "value": 5}, "1": {"name": "cob_id", "type": "UINT32", "value": 0x00000185}, // 0x180 + 5 = 0x185 "2": {"name": "transmission_type", "type": "UINT8", "value": 1}, // 1=Sync, 255=Cyclic "3": {"name": "inhibit_time", "type": "UINT16", "value": 50000}, "4": {"name": "compatibility_entry", "type": "UINT8", "value": 0}, "5": {"name": "event_timer", "type": "UINT16", "value": 0} }}, "0x1A00": {"name": "tpdo1_mapping", "type": "RECORD", "subobjects": { "0": {"name": "max_subindex", "type": "UINT8", "value": 3}, "1": {"name": "mapped_object1", "type": "UINT32", "value": 0x20010010}, // 0x2001:00, 16 bits "2": {"name": "mapped_object2", "type": "UINT32", "value": 0x20010120}, // 0x2001:01, 32 bits "3": {"name": "mapped_object3", "type": "UINT32", "value": 0x20010220} // 0x2001:02, 32 bits }}, "0x2001": {"name": "sensor_data", "type": "RECORD", "subobjects": { "0": {"name": "status", "type": "UINT16", "access": "ro", "value": 0x0000}, "1": {"name": "temperature", "type": "INT32", "access": "ro", "value": 0}, "2": {"name": "humidity", "type": "INT32", "access": "ro", "value": 0} }} }

这个JSON定义了：

• 设备类型为0x00000001（通用设备）
• 心跳周期1秒
• 节点ID=5（体现在0x1800:01的COB-ID=0x185）
• TPDO1映射了三个OD条目：0x2001:00（16位状态）、0x2001:01（32位温度）、0x2001:02（32位湿度）
• 所有传感器数据初始值为0，且为只读（ro）

4.4 主程序编写：app_main.c与canopen_node.c

main/app_main.c（初始化框架）：

#include "freertos/FreeRTOS.h" #include "freertos/task.h" #include "esp_system.h" #include "esp_log.h" #include "canopen_node.h" static const char *TAG = "main"; void app_main(void) { ESP_LOGI(TAG, "Starting CANopen Slave Node..."); // 1. 初始化CAN总线（CAN0） can_bus_handle_t can_bus = can_bus_init(CAN_BUS_0); if (!can_bus) { ESP_LOGE(TAG, "Failed to init CAN bus"); return; } // 2. 初始化CANopen节点（节点ID=5） co_node_t *node = co_node_create(5, can_bus); if (!node) { ESP_LOGE(TAG, "Failed to create CANopen node"); return; } // 3. 启动节点（进入PRE-OPERATIONAL） co_node_start(node); // 4. 创建应用任务，负责传感器采集与OD更新 xTaskCreatePinnedToCore( sensor_task, "sensor_task", 4096, node, 5, NULL, 0 ); // 5. 主循环：运行CANopen协议栈 while(1) { co_node_process(node); // 核心协议栈循环 vTaskDelay(1 / portTICK_PERIOD_MS); // 1ms tick } }

main/canopen_node.c（传感器任务与OD更新）：

#include "freertos/FreeRTOS.h" #include "freertos/task.h" #include "esp_log.h" #include "canopen_core.h" #include "od_manager.h" static const char *TAG = "sensor"; // 模拟传感器读数（实际项目中替换为DHT22/AM2301驱动） static int32_t read_temperature(void) { return 2500; } // 25.00°C static int32_t read_humidity(void) { return 6500; } // 65.00% void sensor_task(void *pvParameters) { co_node_t *node = (co_node_t *)pvParameters; uint32_t last_update_ms = 0; while(1) { uint32_t now_ms = xTaskGetTickCount() * portTICK_PERIOD_MS; // 每100ms更新一次OD（匹配TPDO周期） if (now_ms - last_update_ms >= 100) { last_update_ms = now_ms; // 更新OD条目 0x2001:01 (temperature) od_write_value(0x2001, 0x01, &read_temperature(), sizeof(int32_t)); // 更新OD条目 0x2001:02 (humidity) od_write_value(0x2001, 0x02, &read_humidity(), sizeof(int32_t)); // 更新OD条目 0x2001:00 (status)，置位bit0表示数据有效 uint16_t status = 0x0001; od_write_value(0x2001, 0x00, &status, sizeof(uint16_t