[Enhansment] 对stm32H7-drv_fdcan.c 的一些改进

Describe problem solved by the proposed feature

hello，rtt的维护者们，之前有问过问题，就是自己正好有需求用stm32来做CANFD的一些应用，发现rthhread的bsp/stm32/libraries/HAL_drivers/drivers中并没有drv_fdcan.c， 是从artpi的例程中找到了drv_fdcan.c, 但是这个只支持CAN normal的配置，目前我对drv_fdcan.c有一些小的修改，请问是将这个文件PR到bsp/stm32/libraries/HAL_drivers/drivers这个文件夹中，还是新提一个BSP例程。

Describe your preferred solution

drv_fdcan.c框架已经很完整了，只做了如下一点改进

• 修复编译报错, 原因设备驱动与主线can.c/h定义的结构体使用有差异，导致错误
  

• 完善参数设置

  根据数据手册，FDCAN是完全兼容bxCAN，因此我建议drv_fdcan.c就直接配置成FD模式，发送的帧类型由应用层控制

  • 根据FDCAN的时钟来进行 仲裁域的设置，数据域的配置，包括波特率以及采样率, _stm32_fdcan_NTconfig_t可以将这个结构体扩充信息，来完成FD的配置

  • 由于HAL库的len长度超过8bytes之后是根据DLC解析的，因此还需要一个len -> DLC的转化函数

  • 包括且不限于自动重传等配置

  • 打开硬件过滤会因为没有设置config.maxhdr而导致的报错

• 上层CAN帧发送参数的传递

  rt_can_msg这个结构体里面是有fd_frame的成员的，因此驱动需要跟这个标志为来发送CAN Frame或者 CAN FD Frame，目前可以在TJ1042的收发器上发送CAN Frame或者 CAN FD Frame.
  

Describe possible alternatives

No response

Start by comparing bsp/stm32/libraries/HAL_drivers/drivers/drv_fdcan.c with the mainline can.c/h definitions and the existing stm32H7-drv_fdcan.c changes described in the issue. Then trace rt_can_msg, _stm32_fdcan_NTconfig_t, and the hardware-filter configuration to identify the required compile and parameter changes. Done means the driver builds and supports the stated CAN and CAN FD frame and configuration cases.