CAN: add frame receive timestamp#87
Open
xarantolus wants to merge 1 commit into
Open
Conversation
This allows users to implement time synchronization based on CAN timings.
Contributor
There was a problem hiding this comment.
Pull request overview
Adds reception timestamps to CAN frames to support user-space time synchronization based on CAN SOF timing, by enabling bxCAN timestamp capture and exposing an extended timestamp through the HAL boundary into Rust.
Changes:
- Enable bxCAN time-triggered mode (TTCM) and extend the 16-bit RX SOF timestamp to a per-slot 64-bit counter in the ISR path.
- Extend the C
can_frame_tABI and RustFramestructs to carryhw_timestamp_rx, and plumb the value throughcan_receive. - Add host-side Rust unit tests that specify the timestamp wrap-extension behavior to keep Rust/C logic aligned.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
src/drivers/can.rs |
Adds test-only spec for wrap-extension behavior (and documents timestamp semantics). |
machine/cortex-m/st/stm32l4/interface/export.h |
Extends can_frame_t with hw_timestamp_rx for RX timestamps. |
machine/cortex-m/st/stm32l4/interface/can.c |
Enables TTCM and implements 16→64-bit RX timestamp wrap-extension in drain_fifo(). |
machine/cortex-m/src/stub/can.rs |
Mirrors the new timestamp field in the stub Frame. |
machine/cortex-m/src/native/can.rs |
Mirrors/plumbs the new timestamp field across the Rust↔C boundary. |
Comments suppressed due to low confidence (1)
src/drivers/can.rs:259
- This comment treats the wrap period as a fixed ">65.5 ms" gap, but the wrap time depends on CAN bitrate (wrap period = 65536 bit-times, i.e., 65536/bitrate seconds). Consider expressing the limitation in bit-times or in terms of bitrate to keep it correct for non-1Mbps configurations.
fn idle_gap_longer_than_one_epoch_undercounts_is_known_limitation() {
// Known caveat: a >65.5 ms RX gap hides full wraps (the `<`
// rule sees only one). Fine — sync traffic is far faster.
assert_eq!(run(&[100, 90]), [100, 0x1_0000 + 90]);
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+201
to
+202
| /// Value units: CAN bit-times since boot; wall-time conversion is the | ||
| /// consumer's job (divide by bitrate). |
Comment on lines
+429
to
+431
| * so dropped frames still advance the tracker. Caveat: a >65.5 ms | ||
| * gap with no RX frame hides a wrap — fine, sync traffic is | ||
| * periodic and far faster than that. */ |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This allows users to implement time synchronization based on CAN timings.