nuttx/can: in trunk support to Send message cancel mechanism. #17694
Conversation
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
OceanfromXiaomi
requested review from
acassis,
jerpelea,
michallenc and
simbit18
as code owners
github-actions
bot
added
Area: Drivers
OceanfromXiaomi
force-pushed
the
send_msg_cancel_logic
branch
from
2f1e894 to
180f5f9
Compare
Contributor
|
@OceanfromXiaomi fix: |
acassis
requested changes
Dec 26, 2025
michallenc
requested changes
Dec 26, 2025
OceanfromXiaomi
force-pushed
the
send_msg_cancel_logic
branch
3 times, most recently
from
63c1bf3 to
aef5984
Compare
Contributor
Author
Done |
OceanfromXiaomi
force-pushed
the
send_msg_cancel_logic
branch
from
aef5984 to
1c9a2d1
Compare
acassis
requested changes
Jan 4, 2026
Contributor
acassis
left a comment
acassis
left a comment
There was a problem hiding this comment.
@OceanfromXiaomi please update the Documentation: https://nuttx.apache.org/docs/latest/components/drivers/character/can.html to include this new functionality
OceanfromXiaomi
force-pushed
the
send_msg_cancel_logic
branch
from
1c9a2d1 to
45c74c9
Compare
github-actions
bot
added
the
Area: Documentation
Contributor
Author
Done, @acassis |
acassis
previously approved these changes
Jan 5, 2026
OceanfromXiaomi
force-pushed
the
send_msg_cancel_logic
branch
2 times, most recently
from
85327d4 to
a72f46f
Compare
Introduce a single configuration option to provide strict transmit priority ordering based on CAN ID. The intention is to expose the user-visible behavior (strict TX priority ordering) rather than the underlying implementation details. Strict priority ordering is only meaningful when hardware transmit buffer cancellation is available, so splitting this functionality into separate configuration options was misleading and could result in partially effective or incorrect configurations. Signed-off-by: zhaohaiyang1 <zhaohaiyang1@xiaomi.com>
OceanfromXiaomi
force-pushed
the
send_msg_cancel_logic
branch
from
a72f46f to
7291cec
Compare
xiaoxiang781216
approved these changes
Jan 6, 2026
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
add the logic about "cancel mechanism" of sending can/canfd message based priority list.
Summary
This PR is intended to resolve the CAN message priority inversion issue that can occur during CAN frame transmission.
It fundamentally addresses the problem of CAN message priority inversion, thereby avoiding communication latency or errors caused by priority inversion.
The solution manages CAN message transmission by introducing a cancel mechanism combined with a linked list, along with predefined cancel conditions (can_txneed_cancel), to control and reorder CAN frame transmission as needed.
Impact
If users want to use this scheme, they only need to enable CONFIG_CAN_TXCANCEL.
This scheme does not affect the build process, security, or compatibility.
A new dev_cancel interface is introduced, which is used to cancel the transmission of CAN messages that are already queued in the CAN driver’s hardware transmit buffer.
Testing
This scheme has been applied in an automotive basic-software project and has undergone long-term testing and validation; it does not break existing code.
The scheme also ran stably on development boards based on the Cortex-M7 architecture.
Test procedure:
Observed behavior:
the high-priority message (ID 0x111) appears on the bus first, followed by the low-priority message (ID 0x222).