Repository navigation
[fix] gd32: can: add IRQ aliases and init fixes for legacy series - #11145
illustriousness wants to merge 1 commit into
Conversation
- add CAN0 IRQ alias macros for F10x/F30x/E50x - guard optional CAN1 IRQs - adjust RX pin mode and auto-retrans handling
|
👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。 🛠 操作步骤 | Steps
完成后，提交将自动更新至 如有问题欢迎联系我们，再次感谢您的贡献！💐 |
| if (CAN1 == can_dev->can_x) | ||
| { | ||
| #if defined(CAN1_RX0_IRQn) | ||
| nvic_irq_enable(CAN1_RX0_IRQn, 1, 0); |
There was a problem hiding this comment.
我看上面的CAN0修改成了 CAN0_RX0_IRQn_ALIAS，CAN1的这块是否也需要修正？
还是说这个MCU只有一路CAN？
There was a problem hiding this comment.
我看上面的CAN0修改成了
CAN0_RX0_IRQn_ALIAS，CAN1的这块是否也需要修正？ 还是说这个MCU只有一路CAN？
can1 基本在CL型 中才有 我看pkg下 can1的中断名字都是这个
这个mcu中 只有一路can 不过库中有定义can1
更完善一下的话 可以把上面的ifdef CAN1 直接改成下面的#if defined(CAN1_RX0_IRQn)
There was a problem hiding this comment.
我看上面的CAN0修改成了 ，CAN1的这块是否也需要修正？还是说这个MCU只有一路CAN？
CAN0_RX0_IRQn_ALIAScan1 基本在CL型 中才有 我看pkg下 can1的中断名字都是这个 这个mcu中 只有一路can 不过库中有定义can1 更完善一下的话 可以把上面的ifdef CAN1 直接改成下面的#if defid（CAN1_RX0_IRQn）
纠正一下 GDH7XX 的can1不符合CAN1_RX0_IRQn这样
|
然后建议把驱动添加到ci看护中： https://club.rt-thread.org/ask/article/5edd0f0940a57129.html |
| #ifdef RT_CAN_USING_HDR | ||
| config.maxhdr = 14; | ||
| #ifdef CAN1 | ||
| #ifdef CAN1_EWMC_IRQn |
There was a problem hiding this comment.
这块为什么只针对CAN1进行了处理，我看也有 CAN0_EWMC_IRQn 的定义：https://github.com/RT-Thread-packages/gd32-arm-cmsis/blob/6bc3d6b0f2e077d17d5e14222237fa155f9d143d/GD32F5xx/GD/GD32F5xx/Include/gd32f5xx.h#L129
| #ifdef CAN1 | ||
| if (CAN1 == can_dev->can_x) | ||
| { | ||
| #if defined(CAN1_TX_IRQn) |
There was a problem hiding this comment.
因为有的系列头文件是两个can都定义了的
定义了can1 不代表就能用 但是使用这个irqn可以区分出来这个板子支不支持can1
|
这个等我有空审查一下吧，先暂时别合并 |
请问这个是指针对can这块 还是其他呢 |
can即可，和pr内容相关即可 |
我想 如果强行兼容所有的gd芯片 是否会导致维护越来越困难 |
|
这个 PR 挂了一段时间，做了几项静态核查，把结论整理在这里，可能对推进有用。没有跑编译，原因在最后。 1. 补丁本身没有过期，可以直接合入当前 master用两个 blob 直接比对并做应用检查：
改动 +47/-19，与 PR 页面的统计一致，不需要 rebase。文件 drv_can.c 在当前 master 上仍是 1064 行，上下文都对得上。 2. "缺 CI 证据"的根因：legacy 系列根本没有 BSP 把 CAN 接进 KconfigRbb666 之前建议"把驱动添加到 CI 看护中（can 即可）"。我查了一下当前树内 BSP_USING_CAN 的分布：
只有这两个 BSP 暴露了 CAN 开关，而且都是新系列。 本 PR 改的 legacy 系列（SOC_SERIES_GD32F10x / GD32F30x / GD32E50x）——例如 gd32105r-start、gd32305r-start——它们的 �oard/Kconfig 里连 BSP_USING_CAN 都没有定义。 也就是说：当前树内没有任何现成配置能执行到这个 PR 改动的 IRQ 别名与初始化路径。这不是作者不愿意给 CI 结果，而是要先补一层 BSP 的 Kconfig/编译接入，legacy 系列才可能被 CI 覆盖。 如果 Rbb666 说的"添加到 CI 看护"是指这个，那么工作量其实分两块：驱动侧（本 PR）+ BSP 侧的 CAN 接入。建议明确一下是要求本 PR 一并带上，还是先合驱动、BSP 接入另开一条。 3. 两点会影响合并的操作性问题a) 这个 PR 目前仍是 Draft。 草稿状态的 PR 不会进入评审队列——这很可能是它九个月没有进展的直接原因之一。作者侧只要点一下 "Ready for review"，它才会出现在 kurisaW 的待审列表里。 b) 讨论停在设计分歧上，而不是代码问题上
作者提的按系列拆分的顾虑是合理的：本 PR 已经在 can_baudrate_tbl 和 IRQ 别名上堆叠了 #if defined(GD32F405) || ... 这类条件，系列越多，这段越难维护。这是一个需要维护者拍板的架构取舍，不是作者能自行解决的，建议维护者给个明确方向：是接受条件编译继续堆叠，还是同意作者按系列拆分（那本 PR 的范围会变大）。 4. 为什么我没跑编译试过在 �sp/gd32/arm/gd32450z-eval 上打开 BSP_USING_CAN 编译，卡在：
GD32 BSP 依赖外部 package，我这个环境离线拿不到。所以以上全部是静态核查结论，编译与运行均未验证，请不要把它当成 CI 结果的替代。 如果维护者需要一个有 CI 环境的人来跑这一步，或者希望我把 legacy BSP 的 CAN Kconfig 接入先做出来（这样 CI 才有东西可跑），都可以指定，我按方向继续。 |
This branch has not been deployed
4 participants
拉取/合并请求描述：(PR description)
[
为什么提交这份PR (why to submit this PR)
你的解决方案是什么 (what is your solution)
请提供验证的bsp和config (provide the config and bsp)
]
当前拉取/合并请求的状态 Intent for your PR
必须选择一项 Choose one (Mandatory):
代码质量 Code Quality：
我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:
#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up