【睿擎工业开发平台】从CAN总线到Web界面，打造车载空调风机域控原型|技术集结

时间：2026-06-25作者：财阀佳分类：时尚科技浏览：3563

项目背景

本项目基于睿擎派RC3506J开发板，实现了一套车载空调风机CAN总线控制系统原型。系统以RC3506J作为空调域控制器下的智能上位机，通过CAN FD控制器（can0，500kbps）与STM32G474 FOC电机驱动板通信，构建了完整的”域控—执行”两级架构。RC3506J端部署RT-Thread操作系统与webnet网络组件，提供基于Web浏览器的图形化控制界面，支持电机启停、转速调节、正反转切换及故障管理；STM32G474端利用MCSDK的mc_api接口实现FOC矢量控制，两端的CAN协议层复用与ST Motor Pilot相同的底层API，做到了对原厂控制代码的无侵入接入。

项目完整模拟了车载空调风机的控制链路：空调域控制器（RC3506J）通过车载CAN总线向风机驱动器（STM32G474）下发目标转速指令，风机驱动器回传实时转速、运行状态与故障码，域控制器将数据转发至车载以太网供中控屏或诊断工具访问。本原型为后续扩展AUTOSAR CAN协议栈、UDS诊断服务及OTA升级提供了清晰的软件框架。

硬件平台

本系统由两级硬件构成：RC3506J负责通信管理与人机交互，STM32G474负责电机实时控制。

主控设备：睿擎派RC3506J

睿擎派RC3506J是上海睿赛德电子推出的工业级评估板，搭载瑞芯微RK3506处理器（三核Cortex-A7 + 单核Cortex-M0异构架构），片内集成CAN FD控制器、双以太网GMAC和丰富的GPIO资源。本次试用重点评估了以下三项核心外设：

CAN FD控制器（can0）：兼容CAN 2.0与CAN FD协议，支持最高8Mbps数据段速率。本项目配置为500kbps经典CAN模式，通过GPIO0_C3(TX)/GPIO0_C4(RX)与外部CAN收发器连接。RK3506的CAN FD IP支持硬件自动重发、总线错误诊断和灵活的过滤器配置。

以太网（GMAC0）：板载RGMII PHY，本项目配置静态IP 192.168.1.30，承载webnet轻量级Web服务器，为PC/手机浏览器提供控制界面访问入口。

RT-Thread操作系统：睿擎派出厂预装RT-Thread，内核支持多线程调度、信号量/互斥量IPC、设备驱动框架（CAN、GMAC）及webnet组件，极大降低了应用层开发门槛。

执行设备：STM32G474 FOC驱动板

STM32G474RET6 MCU，ARM Cortex-M4F @170MHz，集成FDCAN控制器与CORDIC加速器

X-NUCLEO-IHM16M1功率板，基于STSPIN830驱动3-Shunt BLDC/PMSM电机

ST MCSDK生成的FOC固件基础，预留USER CODE插入点供CAN功能扩展

系统互联拓扑

项目分析与实现

CAN总线通信协议设计

系统定义了一套精简的8字节CAN应用层协议，命令帧与状态帧各占一个标准ID：

RC3506J侧软件架构

RC3506J端程序（motor_control.c）采用分层设计：

CAN设备层：基于RT-Thread CAN 设备框架，完成事件回调掩码配置→SET_BAUD(500k)→中断模式打开→注册RX indicate回调→创建RX接收线程的标准初始化流程。

协议解析层：RX线程通过信号量阻塞等待CAN帧到达，解析状态帧(0x201)提取float转速、uint8运行状态、uint16故障码和uint8控制模式，更新全局g_motor_status缓存。

CGI应用层：注册5个webnet CGI端点（/cgi-bin/start, stop, speed, fault_ack, status），浏览器通过AJAX轮询status端点（100ms周期）获取实时数据，通过start/stop/speed端点下发控制指令。

Web前端：单页HTML，SVG环形转速表盘、启停/故障按钮、速度滑块、斜坡时间输入框，状态徽章和故障码显示。

STM32G474侧软件架构

can_control.c在USER CODE区块嵌入，复用mc_api.h全部接口，与ST Motor Pilot走同一调用路径。

FDCAN配置：500kbps经典CAN（Prescaler=17, Seg1=9, Seg2=10），全局过滤器接收全部标准帧至RX FIFO 0，软件层按ID=0x200筛选指令。

CAN_Control_Process()在MC_RunMotorControlTasks()中被周期调用（500μs粒度），轮询RX FIFO并定时100ms发送状态帧。

关键原则：不修改Src/Inc之外的库代码——CAN功能完全在USER CODE区实现。

RT-Thread应用开发要点

睿擎派RC3506J出厂即支持RT-Thread，无需底层移植。本项目侧重于利用RT-Thread的CAN设备框架和webnet组件进行应用开发。

一、打通CAN总线通信

RK3506的CAN FD驱动（rockchip,rk3506-canfd）采用RT-Thread CAN总线驱动框架。核心要点：

1. 设备初始化顺序

RK3506 CAN驱动要求严格的初始化顺序——事件回调掩码必须在SET_BAUD之前设置，否则驱动内部状态机无法正确启动异步发送线程：

/* 正确顺序 */rt_device_control(dev,RT_CAN_CTL_SET_EVENT_CALLBACK_MASK, ...); // 先rt_device_control(dev,RT_CAN_CTL_SET_BAUD, (void*)baud_val); // 后rt_device_open(dev,RT_DEVICE_FLAG_INT_TX|RT_DEVICE_FLAG_INT_RX);

2. 波特率参数传递方式

CAN 框架中，SET_BAUD接收void参数，RK3506驱动将其直接解释为波特率整数值（而非指针解引用）。必须使用`(void )CAN500kBaud值传递形式，而非&baud`指针传递形式，否则驱动将把栈地址误认为波特率值。

staticrt_uint32_tcan_baud = CAN500kBaud;rt_device_control(can_dev, RT_CAN_CTL_SET_BAUD, (void*)can_baud); // 正确：值传递

3. CAN消息结构体字段

CAN的rt_can_msg采用位域定义，包含fdf（CAN FD标志）、brs（速率切换）、priv（优先级）和sync（同步/异步模式）等扩展字段。这些字段不应使用memset清零后依赖默认值，而应显式赋值：

structrt_can_msg msg;msg.priv = LOW_PRIORITY;msg.sync =CAN_SYNC;msg.fdf =CAN_20;

4. 接收路径：信号量+线程模式

RK3506 CAN FD驱动不支持定时器轮询rt_device_read——该路径在不注册RX indicate回调时静默返回空。正确做法是注册rt_device_set_rx_indicate回调，在ISR中释放信号量，由独立接收线程阻塞等待信号量后读取帧。这一模式已在can_loopback_test命令中充分验证。

/* RX indicate (ISR) */staticrt_err_tcan_rx_indicate(rt_device_tdev,rt_size_tsize){ rt_sem_release(can_rx_sem); returnRT_EOK;}/* RX thread */staticvoidcan_rx_thread_entry(void*param){ while(can_rx_run) { rt_sem_take(can_rx_sem, ...); rt_device_read(can_dev,0, &rx_msg,1); /* 解析并更新 g_motor_status */ }}

二、webnet组件集成

利用webnet的CGI注册机制（webnet_cgi_register），将5个API端点映射到对应的C函数

CGI handler直接调用can_send_frame写入CAN设备，同步返回JSON确认

status端点读取全局缓存g_motor_status，无需阻塞等待——数据由RX线程异步刷新

Web前端采用纯静态HTML+CSS+JS，通过AJAX定时轮询实现实时数据更新

遇到的问题与解决办法

问题：CAN通信波特率不匹配

RK3506 CAN FD驱动的默认波特率由DTS时钟树决定（200MHz CAN时钟 → 约1.47Mbps仲裁段 + 2Mbps数据段），调用rt_device_control(SET_BAUD, 500k)后驱动返回RT_EOK但实际未生效，且报”device has been opened”错误。

解决：将STM32G474的FDCAN波特率匹配至RK3506默认值（500kbps经典CAN模式），使两端速率一致。

效果展示

系统上电后，在MSH终端执行cmd_motor_control启动服务：

msh />cmd_motor_control[motor] Starting motor control web server...[motor] CAN opened OK @500kbps[motor] RX thread started[motor] CANinitdone[motor] Webnet startedwithCGI handlers

PC浏览器访问http://192.168.1.30/，显示图形化控制界面：中央SVG环形表盘实时显示转速（正向绿色/反向橙色/停止灰色），下方状态徽章指示IDLE/RUN/FAULT等运行状态。控制面板提供启停按钮、速度滑块（-2000~+2000 RPM）、斜坡时间设定框（100~10000ms）和故障确认按钮。页面以100ms周期AJAX轮询status端点，表盘动画流畅。

STM32驱动板侧，CAN指令通过MC_StartMotor1()/MC_ProgramSpeedRampMotor1_F()直达FOC算法层，电机按设定斜坡平滑调速，实际转速经CAN状态帧回传至RC3506J并实时呈现在Web界面。

试用感想

睿擎派RC3506J在此次车载空调风机控制原型的开发中展现了令人印象深刻的综合能力。

硬件层面，RK3506的异构多核架构为”通信+控制”分工提供了天然的硬件基础——Cortex-A7核心承载RT-Thread操作系统、webnet网络协议栈和CAN设备管理，Cortex-M0核心可用于实时性要求更高的底层逻辑。片内CAN FD控制器与双以太网的组合，完美契合车载域控制器的通信需求：CAN总线能够接入车身控制网络，以太网能够支持连接车内信息娱乐系统或诊断网关。

软件生态层面，RT-Thread的统一设备模型和丰富的组件库（webnet、finsh/MSH）将应用层与驱动层解耦，大幅缩短了从原型到验证的开发周期。MSH命令行工具在调试阶段尤为实用——can_loopback_test命令帮助快速定位了CAN收发路径的关键差异，成为排障的核心手段。

开发体验方面，睿擎派RC3506J在SDK中提供了非常丰富的例程，几乎涵盖了各个关键组件。这使得我在开发的过程中可以快速上手改造，实现自己的想法，而且可以看到官方开发人员仍在对SDK保持热点更新维护，持续加入更多的应用示例，这一点非常值得点赞！

总结：RC3506J在工业控制、汽车电子等需要CAN总线+以太网双通道通信的场景中具有显著的平台优势。其强大的处理性能、完善的外设集成和RT-Thread的生态加持，使其成为从原型验证到量产部署的理想选择。期待睿擎派后续在驱动成熟度、SDK文档完善度和典型应用参考设计方面持续投入，进一步降低开发者的接入成本。

最后感谢RT-Thread和睿擎派提供的试用机会！

本文为RT-Thread论坛用户「枫雪天」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：

https://club.rt-thread.org/ask/article/f70f94fbecf64f8f.html

继续浏览有关 rt-thread 的文章

上一篇：41岁的C罗，迟来的“双响” 下一篇：中国音乐学院第三届美育(音乐)展演暨辽宁暑期考级新闻发布会在沈召开