feat(can): 实现非阻塞发送机制并增强CAN驱动功能#10712
Conversation
github-actions
bot
added
BSP: STM32
📌 Code Review Assignment🏷️ Tag: bsp_stm32Reviewers: @Liang1795 @hamburger-os @wdfk-prog Changed Files (Click to expand)
🏷️ Tag: componentsReviewers: @Maihuanyi Changed Files (Click to expand)
🏷️ Tag: components_driver_canReviewers: @wdfk-prog Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2025-09-20 15:03 CST)
📝 Review Instructions
|
There was a problem hiding this comment.
Pull Request Overview
This PR implements a non-blocking send mechanism for the RT-Thread CAN driver framework, enhancing the existing blocking-only transmission capabilities. The implementation adds support for ISR-safe message transmission through software ring buffers and dynamic memory allocation options.
- Added non-blocking CAN message transmission with software ring buffer management
- Enhanced API documentation and example code with bilingual (English/Chinese) comments
- Introduced new configuration options for buffer sizing and memory allocation strategies
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 10 comments.
| File | Description |
|---|---|
| components/drivers/include/drivers/dev_can.h | Added non-blocking flag to rt_can_msg struct, new ring buffer fields to device struct, and comprehensive API documentation |
| components/drivers/can/dev_can.c | Implemented core non-blocking transmission logic, enhanced error handling, and added ISR-safe buffer management |
| components/drivers/can/Kconfig | Added configuration options for non-blocking buffer size and dynamic allocation |
| bsp/stm32/libraries/HAL_Drivers/drivers/drv_can.c | Implemented STM32-specific non-blocking send function and updated ops structure |
📌 Code Review Assignment🏷️ Tag: bsp_stm32Reviewers: Liang1795 hamburger-os wdfk-prog Changed Files (Click to expand)
🏷️ Tag: componentsReviewers: Maihuanyi Changed Files (Click to expand)
🏷️ Tag: components_driver_canReviewers: wdfk-prog Changed Files (Click to expand)
📊 Current Review Status (Last Updated: 2025-09-27 09:42 CST)
📝 Review Instructions
|
wdfk-prog
force-pushed
the
can
branch
2 times, most recently
from
d1c21da to
0c568ff
Compare
illustriousness
left a comment
illustriousness
left a comment
There was a problem hiding this comment.
目前我使用can的大部分场景都是非阻塞发送 支持作者
不过 我在想以下两种情况哪个更好一点
- 在设备打开的时候就选择阻塞或者非阻塞
- 作者目前的想法：发送can消息设置标志位
|
|
@unicornx 汪老师，涉及到 doxygen 部分可以帮忙review下吗？ |
…er functionality - Added support for non-blocking mode CAN message sending, including software ring buffer management and dynamic memory allocation options. - Improved related comments and error handling. - Updated example code to demonstrate the usage of both blocking and non-blocking sending modes, and corrected some structure field naming and macro definitions.
unicornx
left a comment
unicornx
left a comment
There was a problem hiding this comment.
我只看了 doxygen 注释部分，LGTM。
|
@wdfk-prog HI，看上去这个PR没考虑发送完成通知用户的目的？ 如果消息放标志位识别是不是非阻塞，那么假设我需要知道nonblocking的每帧通知应用是否发送完成，看上去在rt_hw_can_isr里面没法做callback通知发送完成，有条件缺失，判断nonblocking部分是用sendmsg_nonblocking是否注册来判断。反而如果在发送前 rt_device_control加个阻塞或者非阻塞，这样在中断callback处理更为方便。 |
|
@wdfk-prog 感谢回复，明白你最初的想法就是当CAN的硬件FIFO满了之后，接下来的CAN帧可以放在ringbuffer以便可以在中断持续发送，做到即使CAN硬件FIFO不足也不至于丢包。
|
5 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