RT-Thread-FRDM-MCXN947 RT-Thread的CAN实践——控制GM6020云台电机RT-Thread问答社区

FRDM-MCXN947 RT-Thread的CAN实践——控制GM6020云台电机

发布于 2024-04-18 20:06:04 浏览：475 订阅该版

[tocm]

# 写在前面
[上一篇帖子](上一篇帖子https://club.rt-thread.org/addons/askrt/article/update/id/5059 "上一篇帖子")说到RT-Thread未适配FRDM-MCXN947开发板的CAN驱动，这点是错误的😓，是由于我没有仔细学习RT-Thread的配置选项导致的，抱歉误导了大家🥺，特此重写一篇文章分享RT-Thread的CAN驱动使用过程。

# 硬件状况
NXP MCXN947 微控制器是基于双高性能 Arm® Cortex®-M33 核心设计的 MCX N94 和 N54 系列的型号，核心频率高达 150 MHz。它具有两个带有 CAN-FD 支持的 FlexCAN 模块，为汽车和工业应用提供了强大的通信协议支持。对于硬件接口和扩展，FRDM-MCXN947 开发板提供了一系列功能，配备了 SD 卡槽、以太网 Phy 和连接器、高速 USB Type-C 连接器，以及包括 SPI、I2C 和 UART 在内的多种串行接口连接器、Arduino®接口、FRDM接口、FlexIO/LCD接口、SmartDMA/摄像头接口、Pmod™ *DNP、mikroBUS™，为样例程序的开发实践提供了自由的发挥空间。

FlexCAN 是 NXP 提供的一款高度可配置、可合成的核心，实现了 CAN 协议（ISO 11898-1）、具有灵活数据速率的 CAN（CAN-FD）以及 CAN 2.0B 协议规范。 NXP 为 FlexCAN 实现了强大的硬件结构，提供了灵活的消息缓冲区RAM、FIFO、时间戳、自动内部指针处理、DMA 、低功耗模式和丰富的中断支持。并且 FlexCAN 驱动提供了功能层和事务层 API。功能层提供了对外围功能的高度优化实现和灵活使用。

根据[开发板用户手册](https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true "用户手册")（P15）所述，在 FRDM-MCXN947 开发板上仅通过 CAN0 对应的P1_10和P1_11连接到TJA1057 CAN phy，所以本次将使用 CAN0 作为测试的外设。

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240418/360d36e2e463ba8ab2b27c05d628a7fc.png.webp)

# 硬件使用说明

图中红框标出的是开发板提供的CAN接口，其定义已在PCB丝印上注明，只需与测试工具正确连接即可。
![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240418/3df33f3f2266e09a83c93e4f4c939207.png.webp)

# 软件使用说明

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/67a912c1491f3cbcf9904948d8646dce.png.webp)

首先克隆RT-Thread源码到本地，找到FRDM-MCXN947的bsp文件夹

```html
..\rt-thread\bsp\nxp\mcx\mcxn\frdm-mcxn947
```

使用提前装好的[ENV工具](https://download-redirect.rt-thread.org/download/env_release/env-windows-1.5.0.7z "ENV工具")，右键选择ConEmu Here，打开menuconfig

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/0c5d0bbeb53526c1167f3f65e5ef6645.png.webp)

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/4836b1b2f5834f165e17e92fe984e32b.png.webp)

在`RT-Thread Components->Device Drivers`下勾选`[ ]Using CAN device drivers`（硬件过滤器和CAN-FD根据需求选择，这里未选）

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/a586ec67f51e1a73956cc2afd0db381b.png.webp)

输入`scons --target=mdk5`生成Keil工程

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/72f9663737c10612e7b8df7ddbf19ae4.png.webp)

发现新工程内没有添加适配MCX的CAN驱动

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/09969bee61b06f9788308dc71bd5c20e.png.webp)

手动添加一下

```html
rt-thread\bsp\nxp\mcx\mcxn\Libraries\drivers
```

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/7288c750dc2d3d81cde7b9929e9049fa.png.webp)

编译出现error

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/01f60915731a5ce12a7c5fb2a64e4fa0.png)

看到相关位置的内容是灰色
![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/df294ef314b576e3d4db254eb3887f17.png)
原因是BSP_USING_CAN0宏未定义导致的

经过短暂的学习大致了解了Kconfig的用法，于是在board/Kconfig中添加一个选项：

```html
Line 190:
    menuconfig BSP_USING_CAN
            bool "Enable CAN"
            select RT_USING_CAN
            default y
            if BSP_USING_CAN
                config BSP_USING_CAN0
                    bool "Enable CAN0"
                    default n

config BSP_USING_CAN1
                    bool "Enable CAN1"
                    default n
            endif
```

运行menuconfig效果：

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/0c671b8d204214ed4389c80b8d172774.png)

保存退出，重新生成工程，添加can_driver.c,可以看到CAN0相关的设备已经生效：

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/ab216687b5c5aaf10dc57325113be42d.png.webp)

可以正常通过编译：

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240417/d1b429e5df6b26bd24731eb6797fcd45.png)

添加测试文件`can_sample.c`：

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240418/a6e83119fb54355957b768f349026416.png.webp)

同时对`drv_can.c`进行修改

```html
rt-thread\bsp\nxp\mcx\mcxn\Libraries\drivers\drv_can.c
```

取消此处代码的注释

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240418/bd403924e9070b9ddbf428e136240b93.png.webp)

同时在Keil工程文件中找到`DeviceDrivers->can.c`,移出工程并替换为git仓库中的`can.c`
> (此处`can.c`主要修改了发送时的永久等待参数，因为当前版本的源码中，调用`rt_device_write(can_dev, 0, &msg, sizeof(msg));`将导致函数阻塞，经过排查是`drv_can.`c中使用了阻塞发送未能触发`TxIdle`中断导致RT-Thread无法完成发送，但我尝试修改为中断发送方式后，代码确实能运行到`flexcan_callback`的`kStatus_FLEXCAN_TxIdle`分支，最终运行了`rt_completion_done(&(tx_fifo->buffer[no].completion));`仍无法通知函数已完成发送（实际上CAN帧已发送），尽管修改超时时长这种方法非常不优雅，不安全，但小弟能力有限，只能出此下策让代码运行起来了，希望能有大神指点一二😢😢)

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20240418/75c4aaadc4dfdae3968d4af17003846e.png)

# 命令用法：
`can_rx`：执行第一次创建一个接收处理线程，再次执行将会启动打印功能（默认关闭），此后每次执行都将翻转开启状态
`can_tx`：参数格式为 <设备名称> <数据帧CAN ID> <数据帧数量> <每帧间隔时长(毫秒)>

# 代码链接：

```html
https://github.com/Alipay1/frdm_mcxn947_rtt_can
```

# 效果视频：

```html
https://www.bilibili.com/video/BV1TC411G7e8/?vd_source=07d7e67799619eaf71e3464162fbefa0
```

# 心得体会：
在第一篇帖子中，我主要使用了 NXP 提供的 FSL 库，其中提供的默认配置句柄，自动计算 CAN 最优分频值功能让我眼前一亮，能够感受到 FSL 库对开发者的友好态度和其高质量的代码水平，在使用 RT-Thread 的测评过程中，RTT 丰富的软件功能和预留接口所提供的灵活度，极大降低了开发难度，其实现的高效线程调度和多种内核对象的支持为复杂任务的管理提供了极大的便利，这对于开发高性能的嵌入式系统尤为重要。我也认识到了自身水平的不足，接下来将以RT-Thread源码作为榜样，努力学习。
RT-Thread 和 NXP 的合作为开发者提供了一个强大而灵活的开发环境，使得从硬件到软件的整个开发流程更加顺畅。这种一站式的解决方案，不仅可以减少开发周期，还可以在项目初期就确保较高的可靠性和性能。