[CAN]update struct can_filter_item and rt_can_msg

[wdfk-prog]

拉取/合并请求描述：(PR description)

[

为什么提交这份PR:

• can的can_filter_item和rt_can_msg结构体，同一变量名hdr有两种意义，应重新命名
• 接收时之前没有标识是来自RXFIFO0，还是RXFIFO1

解决的问题是什么

1. 对过滤器号和索引号结构体定义中同一名称hdr进行重命名hdr_bank和hdr_index,
2. 添加接收标识rxfifo,已指明是哪个RXFIFO.

为什么提交这份PR:

• STM32 drv_can.c 中42M下的波特率有偏差
• 接收获取索引号错误

解决的问题是什么

1. 更正42M下的波特率
2. 修复接收获取索引号错误
3. 添加接收标识rxfifo,已指明是哪个RXFIFO.

并确认并列出已经在什么情况或板卡上进行了测试。

• 硬件：STM32F429IGT6
• 操作系统版本：V4.1.0
• 使用标准CAN进行测试
• 仅对STM32的drv_can.c进行更新添加RXFIFO标识，其余芯片没有使用，没有更新。

参考

https://club.rt-thread.org/ask/question/b55f0958204830cd.html

BSP修改的代码

BSP芯片	修改文件	是否测试
at32	drv_can.c	否
essemi/es32f0654	drv_can.c	否
essemi/es32f369x	drv_can.c	否
hc32	drv_can.c	否
hpmicro	drv_can.c	否
imxrt	drv_can.c	否
loongson	drv_can.c	否
n32	drv_can.c	否
n32g452xx	drv_can.c	否
nuvoton/libraries/m2354	drv_can.c	否
nuvoton/libraries/m480	drv_can.c	否
nuvoton/libraries/ma35	drv_can.c	否
nuvoton/libraries/n9h30	drv_can.c	否
nuvoton/libraries/nuc980	drv_can.c	否
renesas	drv_can.c	否
stm32	drv_can.c	是
synwit/swm341	drv_can.c、main.c	否
wch/risc-v	drv_can.c	否

以下的内容不应该在提交PR时的message修改，修改下述message，PR会被直接关闭。请在提交PR后，浏览器查看PR并对以下检查项逐项check，没问题后逐条在页面上打钩。
The following content must not be changed in the submitted PR message. Otherwise, the PR will be closed immediately. After submitted PR, please use a web browser to visit PR, and check items one by one, and ticked them if no problem.

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• 本拉取/合并请求代码是高质量的 Code in this PR is of high quality
• 本拉取/合并使用formatting等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification

[Guozhanxin]

改了这个，其他的bsp的驱动就不能用了啊

[Guozhanxin]

是不是把其他bsp的驱动也改了

[sheltonyu]

hello，大佬们，打扰请教一下。

直接对can.h进行一些类似的调整是否风险太大啊。

#define CAN_RX_FIFO0 (0x00000000U) /*!< CAN receive FIFO 0 /
#define CAN_RX_FIFO1 (0x00000001U) /!< CAN receive FIFO 1 */
接收fifo number的宏定义区分是否应该在各自的底层库中自行进行处理，因各家设计的做法都不尽相同，fifo数量可能只有一个，可能两个，或者更多。
该处统一定义在can框架内，如果各家的底层库中又自行在处理，且命名一样，采用枚举方式定义的就会编译报错。目前发现的at32/esp32采用枚举方式的应该会出现问题。
typedef enum {
CAN_RX_FIFO0 = 0x0U, /< CAN fifo 0 used to receive */
CAN_RX_FIFO1 = 0x1U, /< CAN fifo 1 used to receive */
} can_rx_fifo_t;

另外虽然每次的上传都会有自动check机制，但仿佛都是check的bsp默认配置状态，一些外设驱动并未开启，感觉对这种外设根源性调整的点覆盖不全。

以上仅个人浅见。谢谢

[mysterywolf]

#9611