You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add strict local TX wire ordering on top of PR #8.
The generic CAN framework now defaults to at most one hardware-pending TX request at a time. This prevents a later request from being preloaded into another controller mailbox and overtaking an earlier request because of controller-specific mailbox/identifier priority.
Drivers that can prove ordered transmission with multiple hardware mailboxes may opt into:
RT_CAN_CAP_TX_ORDERED_MAILBOX
and retain multi-mailbox preload.
Ordering contract
For the generic fallback:
framework admission order is FIFO;
only the queue head may be submitted;
a later request cannot bypass queued work;
a failed/busy submit never uses force-overwrite or tail reinsertion;
without RT_CAN_CAP_TX_ORDERED_MAILBOX, the next request is submitted only after the previous hardware-owned request reaches a terminal event.
This addresses the class of ordering problems discussed in RT-Thread issue/PR RT-Thread#11270 while keeping the hardware capability explicit.
Compatibility
The capability is queried through control(RT_CAN_CMD_GET_CAPABILITIES, ...). Existing BSPs that do not implement the command naturally fall back to strict single-pending ordering and require no ISR call-site changes.
Tests
The fake-controller test exposes three mailboxes and submits CAN IDs in the order 0x700 -> 0x100 -> 0x300. With no ordered-mailbox capability, the test verifies that only one request is submitted to hardware at a time and the same application order is preserved across TX_DONE events.
No target-board/hardware validation has been performed in this PR.
👋 感谢您对 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).
Use workflow from 保持默认分支(通常为 master)
Keep the default branch (usually master) in Use workflow from
在 branch 输入框填写 PR 分支 refactor/can-strict-tx-order
Enter PR branch refactor/can-strict-tx-order in the branch field
设置需排除的文件/目录(目录请以"/"结尾)
Set files/directories to exclude (directories should end with "/")
等待工作流完成 | Wait for the workflow to complete
格式化后的代码将作为独立提交推送至你的分支。
The formatting changes will be pushed to your branch as a separate commit.
完成后,提交将自动更新至 refactor/can-strict-tx-order 分支,关联的 Pull Request 也会同步更新。
Once completed, commits will be pushed to the refactor/can-strict-tx-order 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!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add strict local TX wire ordering on top of PR #8.
The generic CAN framework now defaults to at most one hardware-pending TX request at a time. This prevents a later request from being preloaded into another controller mailbox and overtaking an earlier request because of controller-specific mailbox/identifier priority.
Drivers that can prove ordered transmission with multiple hardware mailboxes may opt into:
RT_CAN_CAP_TX_ORDERED_MAILBOXand retain multi-mailbox preload.
Ordering contract
For the generic fallback:
RT_CAN_CAP_TX_ORDERED_MAILBOX, the next request is submitted only after the previous hardware-owned request reaches a terminal event.This addresses the class of ordering problems discussed in RT-Thread issue/PR RT-Thread#11270 while keeping the hardware capability explicit.
Compatibility
The capability is queried through
control(RT_CAN_CMD_GET_CAPABILITIES, ...). Existing BSPs that do not implement the command naturally fall back to strict single-pending ordering and require no ISR call-site changes.Tests
The fake-controller test exposes three mailboxes and submits CAN IDs in the order
0x700 -> 0x100 -> 0x300. With no ordered-mailbox capability, the test verifies that only one request is submitted to hardware at a time and the same application order is preserved across TX_DONE events.No target-board/hardware validation has been performed in this PR.
Stack
PR 4/7. Base: PR #8 (
refactor/can-tx-terminal-timeout).