得益于ST官方的linux系统，已经集成了我们所需要的CAN的驱动程序，因此基于DK1我们实现CAN接口的测试没有驱动方面的障碍了。接下来就是我们如何选择CAN的接口和如果选择那个GPIO的引脚作为CAN的功能使用了。
STM32MP1提供了两组CAN，根据数据手册我们可以总结出来。
FDCAN1的接口：
| GPIO-TX引脚 | GPIO-RX引脚 | 对应功能选择 |
| PA12 | PA11 | AF9 |
| PB9 | PB8 | AF9 |
| PD1 | PD0 | AF9 |
| PH14 | PH13 | AF9 |
| - | PI9 | AF9 |
FDCAN2的接口：
| GPIO-TX引脚 | GPIO-RX引脚 | 对应功能选择 |
| PB7 | PB5 | AF9 |
| PB13 | PB12 | AF9 |
通过DK1-GPIO扩展可以使用的GPIO引脚如下图所示：
FDCAN1可选使用PA12和PA13，功能和I2C5复用；
FDCAN2可选使用PB12和PB13，功能和USART3复用；
设备树文件配置：
我们需要在设备树文件中配置其中一个CAN接口为我们使用，我先配置了FDCAN1作为引出的CAN接口。
&pinctrl{
fdcan1_pins:fdcan1_pins {
pins{
pinmux= , /* FDCAN1_RX */
; /* FDCAN1_TX */
};
};
fdcan2_pins: fdcan2_pins {
pins{
pinmux= , /* FDCAN2_RX */
; /*FDCAN2_TX */
};
};
}；
&m_can1{
pinctrl-names= "default";
pinctrl-0= <&fdcan1_pins>;
status= "okay";
};
&m_can2{
pinctrl-names= "default";
pinctrl-0= <&fdcan2_pins>;
status= "disabled";
};
编译设备树文件下载到系统中，重启系统。测试中发现无论如何都无法完成通讯，经过查询，发现PA11和PA12由于默认功能为I2C5，因此在这个引脚上分别接了1.5K的上拉电阻，影响了FDCAN1的通讯。
不知道这个分析是不是正确，但是我确实没有测试通过，希望有高手测试后可以把经验分享出来。
先禁用FDCAN1测试FDCAN2，调整设备树文件：
&m_can1{
pinctrl-names= "default";
pinctrl-0= <&fdcan1_pins>;
status= "disabled ";
};
&m_can2{
pinctrl-names= "default";
pinctrl-0= <&fdcan2_pins>;
status= " okay";
};
编译下载到目标板，重启系统。再次测试，FDCAN2可以正常测试通过。
CAN接口测试工具：
我们可以编译一个CAN的测试工具can-tuils 。这个工具我们可以在之前的系统中添加，通过menuconfig->Target packages->Networking applicaions选择
然后保存，重现编译系统，我们就可以获取CAN的测试工具了。
CAN接线：
DK1板的扩展接口并没有CAN的物理层，因此我们必须增加一个物理层才能进行测试。
我手头有个恩智浦的测试板Mxdock-1扩展板，可以提供CAN接口的物理层，正好。
还需要一个USB-CAN的测试工具，这个是我自己做的，功能具备，但是比较丑陋。
测试先连接的有点乱，主要连接3根线，GND，TX，RX。
测试结果：
我们通过SSH连接到DK1板上，配置CAN0接口。
波特率配置为125K：
#ip link set can0 type can bitrate 125000
使能can0接口：
#ifconfigcan0 up
运行can的测试软件：
#candumpcan0
Windows端打开测试设备，发送数据，观察dk1上的接收显示。
目标机显示接收
到这里，linux系统上的CAN通讯已经测试成功了，接下来将会在最后的项目中使用到这个接口完成与设备的通讯，并获取和解析数据。
下一贴将要进入异构核间通讯的研究。
