[meng-plus]

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

[

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

当调用CAN通信连续发送N包数据（如序号1 2 3 4 5 6 7 8 ），当发送超过硬件缓存区(3个)时，会将多余的 4 5 6 7 8依次存入ringbuff,并在发送完成中断再次从ringbuff中取出数据写入硬件缓存区，但是由于_can_nonblocking_tx中处理逻辑，每次优先请求硬件是否有空间，再考虑写入缓存区，后发的数据可能先进入硬件缓存区而发送出去
在中断处理RT_CAN_EVENT_TX_DONE中检测ringbuff中是否有数据，先弹出再尝试发送，如果失败又重新压入队列中，也导致了顺序错乱

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

1. _can_nonblocking_tx 中逻辑更换为先尝试硬件能否写入，写入失败后转存缓存区，如果缓存区有数据排队，后续数据只写入ringbuff，而不再尝试请求硬件写入
2. RT_CAN_EVENT_TX_DONE事件中，由于无法确认是否成功写入硬件，因此第一个数据先拿到尝试发送，发送成功后再弹出数据，否则等下次中断

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

• BSP:

• .config:

• 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/ALL_BSP_COMPILE.json 详细请参考链接BSP自查

[github-actions]

👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread!

为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。
To ensure your code complies with RT-Thread's coding style, please run the code formatting workflow by following the steps below (If the formatting of CI fails to run).

---

🛠 操作步骤 | Steps

1. 前往 Actions 页面 | Go to the Actions page
   点击进入工作流 → | Click to open workflow →

2. 点击 Run workflow | Click Run workflow

• 设置需排除的文件/目录（目录请以"/"结尾）
  Set files/directories to exclude (directories should end with "/")
• 将目标分支设置为 \ Set the target branch to：fix.can
• 设置PR number为 \ Set the PR number to：11270

3. 等待工作流完成 | Wait for the workflow to complete
   格式化后的代码将自动推送至你的分支。
   The formatted code will be automatically pushed to your branch.

完成后，提交将自动更新至 fix.can 分支，关联的 Pull Request 也会同步更新。
Once completed, commits will be pushed to the fix.can branch automatically, and the related Pull Request will be updated.

如有问题欢迎联系我们，再次感谢您的贡献！💐
If you have any questions, feel free to reach out. Thanks again for your contribution!

[github-actions]

📌 Code Review Assignment

🏷️ Tag: components

Reviewers: @Maihuanyi

Changed Files (Click to expand)

• components/drivers/can/dev_can.c

🏷️ Tag: components_driver_can

Reviewers: @wdfk-prog

Changed Files (Click to expand)

• components/drivers/can/dev_can.c

---

📊 Current Review Status (Last Updated: 2026-03-19 16:06 CST)

• ⌛ @Maihuanyi Pending Review
• ⌛ @wdfk-prog Pending Review

---

📝 Review Instructions

1. 维护者可以通过单击此处来刷新审查状态: 🔄 刷新状态
   Maintainers can refresh the review status by clicking here: 🔄 Refresh Status

2. 确认审核通过后评论 LGTM/lgtm
   Comment LGTM/lgtm after confirming approval

3. PR合并前需至少一位维护者确认
   PR must be confirmed by at least one maintainer before merging

ℹ️ 刷新CI状态操作需要具备仓库写入权限。
ℹ️ Refresh CI status operation requires repository Write permission.

[BernardXiong]

或许可以对can收发过程中的中断屏蔽机制做个整体的重构？一个是一些计数++的部分，可以使用原子操作的方式；其他部分是否可以semaphore或spinlock进行处理？

[wdfk-prog]

或许可以对can收发过程中的中断屏蔽机制做个整体的重构？一个是一些计数++的部分，可以使用原子操作的方式；其他部分是否可以semaphore或spinlock进行处理？

#11779

[Rbb666]

当前非阻塞发送路径仍可能覆盖已经接受的 CAN 消息，需要修正后再合并。

components/drivers/can/dev_can.c 第 369～374 行在判断软件队列为空后恢复中断，再尝试硬件发送。存在以下交错：线程 A 在恢复中断后被线程或 ISR B 抢占；B 填满硬件邮箱及软件发送队列；A 恢复后硬件发送失败，直接调用 rt_ringbuffer_put_force()，覆盖 B 已入队的旧消息，但仍增加 sent_size 并向调用者报告成功。上层非阻塞写路径没有互斥锁，不能排除这种交错。

原来的此处使用容量检查和普通入队，队列满时返回短写；这次引入的强制覆盖会造成静默丢消息。原评审线程 虽已标记解决，当前 head 中该调用仍然存在。

请重新检查队列容量，禁止覆盖已接受但尚未发送的消息，并保证队列检查、硬件发送和入队之间的同步关系覆盖线程及 ISR 场景。请验证双发送者抢占、硬件邮箱满及软件队列满时，不会丢弃旧消息，返回长度也与实际接受的消息数一致。

[wdfk-prog]

当前非阻塞发送路径仍可能覆盖已经接受的 CAN 消息，需要修正后再合并。

components/drivers/can/dev_can.c 第 369～374 行在判断软件队列为空后恢复中断，再尝试硬件发送。存在以下交错：线程 A 在恢复中断后被线程或 ISR B 抢占；B 填满硬件邮箱及软件发送队列；A 恢复后硬件发送失败，直接调用 rt_ringbuffer_put_force()，覆盖 B 已入队的旧消息，但仍增加 sent_size 并向调用者报告成功。上层非阻塞写路径没有互斥锁，不能排除这种交错。

原来的此处使用容量检查和普通入队，队列满时返回短写；这次引入的强制覆盖会造成静默丢消息。原评审线程 虽已标记解决，当前 head 中该调用仍然存在。

请重新检查队列容量，禁止覆盖已接受但尚未发送的消息，并保证队列检查、硬件发送和入队之间的同步关系覆盖线程及 ISR 场景。请验证双发送者抢占、硬件邮箱满及软件队列满时，不会丢弃旧消息，返回长度也与实际接受的消息数一致。

这个不好修的,机制在这里决定了修起来很困难

• 还是看看推进一下refactor[CAN]: improve CAN driver lifecycle and TX handling #11779