百度对网站建设公司全网营销策划公司

在一个工程中，通常会把对CAN外设的操作分成底层和上层两个部分，从而提高代码的模块化和可维护性。一般来说：

• can.c

  • 通常由硬件抽象层（HAL）或者自动生成工具（如 CubeMX）提供或生成。
  • 主要负责CAN硬件的底层初始化与配置，包括调用 HAL_CAN_Init()、配置中断、GPIO、时钟等硬件资源（在对应的 MSP 函数中进行）。
  • 负责处理与硬件直接相关的操作，提供一组基础的接口函数或回调函数。

• driver_can.c

  • 通常是用户根据具体应用需求编写的上层驱动。
  • 利用 can.c 中提供的低级接口，进一步封装成更易用、功能更完善的驱动接口。
  • 可能包含报文的封装、数据的发送与接收处理、错误管理、协议实现等逻辑，使上层应用调用起来更简单，不用关心硬件初始化等细节。

总结两者关系：

• can.c 提供了与CAN硬件直接交互的底层实现；
• driver_can.c 基于 can.c 的功能，构建了一个更高层次、面向应用的驱动模块，简化了对CAN通信功能的调用和管理。

这种分层结构有助于代码的重用和维护，当底层硬件变化或更新时，只需要修改 can.c，而上层的 driver_can.c 接口则可以保持不变。

• 外设相关的GPIO配置集中在MSP函数中：
  对于专门用于CAN（或其他外设）的GPIO引脚，应在对应的HAL_CAN_MspInit()函数中配置。这样可以确保在初始化CAN外设时，同时完成了CAN所需的引脚、时钟和中断设置。

• 通用GPIO初始化放在gpio.c中：
  gpio.c中一般配置的是应用中用到的通用GPIO，比如LED、按键或其他与外设复用功能无关的引脚。如果CAN的引脚已经在MSP函数中配置，就不必再在gpio.c中重复配置。

• 避免重复初始化：
  如果同一个引脚被重复初始化且配置不一致，可能会导致冲突或不可预期的行为。因此，确保专用于CAN功能的引脚只在HAL_CAN_MspInit()中配置，而不在通用的gpio.c中配置。

总结来说，如果你的工程中已经在CAN的MSP初始化函数中配置了CAN所需的GPIO，那么你无需也不应该在gpio.c中重复配置这些引脚。这样既符合HAL库设计理念，也有利于代码的模块化和维护。

具体来说

can.c中是mx软件生成的配置代码，主要包括can的实例化、初始化以及低级的参数配置，还有中断的设置（指定can接口和fifox接口）如下图所受：

driver_can.c中是高级的开发，主要包括can通信的速率波特率、过滤器、发送函数、接收函数（中断回调函数），触发中断后可在中断函数中解析接收的数据报文：