Conversation
|
👋 感谢您对 RT-Thread 的贡献！Thank you for your contribution to RT-Thread! 为确保代码符合 RT-Thread 的编码规范，请在你的仓库中执行以下步骤运行代码格式化工作流（如果格式化CI运行失败）。 🛠 操作步骤 | Steps
完成后，提交将自动更新至 如有问题欢迎联系我们，再次感谢您的贡献！💐 |
📌 Code Review Assignment🏷️ Tag: componentsReviewers: @Maihuanyi Changed Files (Click to expand)
🏷️ Tag: components_driver_canReviewers: @wdfk-prog Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2026-03-19 16:06 CST)
📝 Review Instructions
|
| if (can->ops->sendmsg_nonblocking(can, pmsg) != RT_EOK) | ||
| { | ||
| level = rt_hw_local_irq_disable(); | ||
| rt_ringbuffer_put_force(&can->nb_tx_rb, (rt_uint8_t *)pmsg, sizeof(struct rt_can_msg)); |
There was a problem hiding this comment.
rt_ringbuffer_put_force强制入队不合适吧?, 应该重新检查是否能够有空间;不然强制丢掉了旧数据
| return -RT_EINVAL; | ||
| } | ||
|
|
||
| level = rt_hw_local_irq_disable(); |
There was a problem hiding this comment.
- 这个中断关的太多了吧,这样子
TX_DONE中断触发不了 - 然后一直入队,不给出队的机会更容易写满
2 participants
拉取/合并请求描述：(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)
请提供验证的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