[bsp][at32] can bus CAN_RX_FIFO defined twice

[koendv]

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

[

为什么提交这份PR (why to submit this PR)

Compilation of CAN device on AT32 fails. CAN_RX_FIFO0 and CAN_RX_FIFO1 are defined twice.
Once in components/drivers/include/drivers/dev_can.h, as a #define.
Once in bsp/at32/libraries/AT32F435_437_Firmware_Library/drivers/inc/at32f435_437_can.h, as an enum.
Hence, compilation fails.

CC build/applications/main.o
In file included from /home/koen/src/rt-thread/components/drivers/include/rtdevice.h:137,
                 from applications/main.c:12:
/home/koen/src/rt-thread/components/drivers/include/drivers/dev_can.h:210:37: error: expected identifier before '(' token
  210 | #define CAN_RX_FIFO0                (0x00000000U)  /*!< CAN receive FIFO 0 */
      |                                     ^
/home/koen/src/rt-thread/bsp/at32/libraries/AT32F435_437_Firmware_Library/drivers/inc/at32f435_437_can.h:261:3: note: in expansion of macro 'CAN_RX_FIFO0'
  261 |   CAN_RX_FIFO0                           = 0x00, /*!< can fifo 0 used to receive */
      |   ^~~~~~~~~~~~
scons: *** [build/applications/main.o] Error 1

你的解决方案是什么 (what is your solution)

In at32f435_437_can.h, undefine CAN_RX_FIFO0 and CAN_RX_FIFO1
If others have encountered the same problem, I would like to know how they solved it.

请提供验证的bsp和config (provide the config and bsp)

• BSP: bsp/at32/at32f435-start

• action:

]

当前拉取/合并请求的状态 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
• 如果是新增bsp, 已经添加ci检查到.github/workflows/bsp_buildings.yml 详细请参考链接BSP自查

[mysterywolf]

@wdfk-prog 看看可否提个PR修改一下这个问题，这个宏当时是您引入进来的，本PR的修改方式肯定是不对的。

[wdfk-prog]

• 可以看到其他的芯片系列,内部yeyou也有定义该宏或者枚举;并没有没问题;
• 应该调整该芯片系列的头文件顺序既可;
• 不然修改CAN_RX_FIFO0的名称的话,改动的范围蛮多的,虽然只是简单的替换;
• 我手上没有这个芯片尝试

[mysterywolf]

• 我建议应该对CAN_RX_FIFO0（是指CAN设备框架的宏，不是HAL库的宏）进行替换，看起来有多个BSP的HAL库与我们CAN设备框架的定义宏重名。即便现在没有冲突，后续可能因为头文件位置移动等机缘巧合的原因，也可能会引入冲突。
• CAN设备框架的宏定义改成RT_CAN_RX_FIFO1 觉得咋样？

[wdfk-prog]

• 我建议应该对CAN_RX_FIFO0（是指CAN设备框架的宏，不是HAL库的宏）进行替换，看起来有多个BSP的HAL库与我们CAN设备框架的定义宏重名。即便现在没有冲突，后续可能因为头文件位置移动等机缘巧合的原因，也可能会引入冲突。
• CAN设备框架的宏定义改成RT_CAN_RX_FIFO1 觉得咋样？

• 可以的

[mysterywolf]

OK 我重新提交PR处理一下

@koendv Thanks for your PR, I will re-implement the PR and submit it. I will close this PR. Thank you~

[mysterywolf]

#6556

[Rbb666]

#6556

这个PR是否可以关闭了？

[koendv]

关闭了。