Conversation
mickeprag
commented
Jan 23, 2026
mickeprag
commented
- Implement CAN FD frame
- Implement a CAN FD interface
liamkinne
left a comment
liamkinne
left a comment
There was a problem hiding this comment.
Just some thoughts on this implementation.
embedded-can/src/blocking.rs
Outdated
| fn transmit_fd(&mut self, frame: &Self::FDFrame) -> Result<(), Self::Error>; | ||
|
|
||
| /// Blocks until a fd frame was received or an error occurred. | ||
| fn receive_fd(&mut self) -> Result<Self::FDFrame, Self::Error>; |
There was a problem hiding this comment.
How does this work for receivers that want to receive both FD and non-FD frames? By your description this would only return FD frames.
There was a problem hiding this comment.
Do you have a suggestion for a signature?
Should we perhaps return an enum that can handle both frame types?
| fn dlc(&self) -> usize; | ||
|
|
||
| /// Returns the length of the frame data in bytes. | ||
| fn length(&self) -> usize { |
There was a problem hiding this comment.
Is this any different to .data().len()? I'm assuming it would be implemented that way anyway.
There was a problem hiding this comment.
The length will be derived from the dlc. So the .data() function must read the dlc anyway to be able to return the correct length for the slice. Doing .data().len() needs to call dlc() internally anyway. I see no reason for the extra roundtrip creating a slice. I am providing a default implementation anyway so consumers of the trait does not need to implement it.
There was a problem hiding this comment.
To be honest, I rather think the implementation will be the other way around. Implementations of data() will be calling the length() method, instead of length() calling data()...
2 participants
