-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CAN Support #100
CAN Support #100
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this PR!
I left some comments, but these are mostly nit-picks. I know this PR is still WIP, so ignore comments which are not applicable.
Disclaimer: I did not have much experience with Can nor did I look into the CAN hal proposal.
src/can.rs
Outdated
} | ||
|
||
impl CanFrame { | ||
pub fn new_with_len(id: CanId, data: &[u8], length: usize) -> CanFrame { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious. Why must the data slice be converted into an array? Slice has a len()
method. Maybe you could give me some insight :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should likely limit the visibility of this method and it could be simplified a bit... The reason this exists is mainly to do with lifetimes and there are sort of two reasons for it:
- is for reading, we allocate an array always of length 8 bytes (the max CAN frame size), because we cant do dynamic allocation and then use a subslice of it, but now that I think more about it, we can likely just consume that array in this case and avoid the reference.
- Is because of how we need to implement
embedded_hal_can::Frame
. Having every frame have a 8 byte backing array was just the simplest way to handle this without getting into usinggeneric_array
or something, but ultimately I may do that, because it would make the code clearer.
@Sh3Rm4n this should be ready for another look when you have some time, it should be mergeable in its current state. A couple notes:
|
@Sh3Rm4n any thoughts on another review or merging this? |
I'm working on getting all the open PRs reviewed, starting with the oldest one. If @Sh3Rm4n is busy I'll take a look once I got to this one. Just to confirm though: Do you consider this ready for merging? I'm asking because there are still two open TODOs. |
I moved those around a bit to be more clear, I do think they would be interesting to tackle in the future but are sort of hard and don't really affect the functionality here much. This should be useable and mergeable as-is. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for keeping you waiting. I've left some comments, but I did not dive into the implementation logic, yet.
let filter = CanFilter::from_mask(0b100, ID as u32); | ||
rx0.set_filter(filter); | ||
|
||
// Watchdog makes sure this gets restarted periodically if nothing happens |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, this is also now an example for the watchdog 👍
|
||
static FILTER_INDEX: AtomicU8 = AtomicU8::new(0); | ||
|
||
pub struct Can { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see more comments / documentation, especially on the public interfaces, like this struct :)
Co-authored-by: Fabian <[email protected]>
Co-authored-by: Fabian <[email protected]>
11ea850
to
6d18d68
Compare
I have updated this to address the open comments. I added a bunch of notes about the usages of unsafe but a lot of those notes are semi silly but calling |
Merge! |
@David-OConnor would love to tho I dont have access 👍 @Sh3Rm4n or @ra-kete I have merged master to address some conflicts as well as updated the changelog, and the build is passing. Any chance one of you could merge this for me when you have a moment? I think all of the comments should be addressed. |
@Sh3Rm4n has reviewed this, so if he gives his thumbs-up for merging I'm fine too. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
src/can.rs
Outdated
return (transmitter, fifo0, fifo1); | ||
} | ||
|
||
pub fn release(self) -> stm32::CAN { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub fn release(self) -> stm32::CAN { | |
pub fn free(self) -> stm32::CAN { |
And it should release gpioa::PA11<AF9>
and gpioa::PA12<AF9>
as well.
updated, the docs are still a bit sparse but unfortunately I don't have a ton of time to work on this ATM. |
Nice. Thanks for the contribution. Finally i've time to merge this 🎉 Thanks for your patience. Further things can still be improved later on, if necessary. |
This PR is fairly incomplete still, though it is functional.
I created a (temp) create called
embedded-hal-can
to try implementing the traits currently in rust-embedded/embedded-hal#77 though that PR is so old now, I am not sure its going to get much traction (and I am not totally sure I love the structure of those traits anyhow) so I may remove that piece.I have been testing this on an
STM32f302C8T6
, I am working on simplifying my "blinky with can" into an example of how to use this.todos:
future improvements:
Wanted to post this now though as I have been sitting on it for a while and I figured it would be good to at least get thoughts/feedback.