Small fixes for CAN #186
Small fixes for CAN #186
Conversation
|
Don't worry about #178 too much. This is still very WIP and for now only contains added TODO comments. More of a reminder for myself. Maybe I should close that PR until it contains some useful changes. |
|
updated this to use a builder + the source enums where possible. Sorry for the delay havent had much time to work on this! |
|
(also didnt realize the clippy lints were failing, fixed now) |
There was a problem hiding this comment.
Sorry for the long delay on my side again. I've to figure out to devote some time regularly to this project. The last active maintenance efforts of myself are reduced to short bursts.
Some very minor nits, the rest looks ok to me. As Can::new() has the same API as before, this is not API break. Changelog entries are always welcome, but in this case not required.
In the long run, we should think about using the https://github.com/stm32-rs/bxcan types,
and in the longer run, see if we can copy / merge some ideas from stm32-rs/stm32f1xx-hal#293.
But this takes time. As of now, I'm really happy, that you are doing this work on the CAN peripheral right now! :)
|
no prob @Sh3Rm4n I am in the same boat myself. I find occasional bouts of time to work on this, but much less than I would prefer! I will make some of those changes later today and update the changelog as well. I totally agree about using |
Nice 👍
Yeah, I know that your original work on CAN predates the
No pressure. Maybe some else has time to pick this up and you can focus on your motor driver! :) |
|
Should be good to merge! |
I know there is an open issue for refactoring the CAN impl (#178) but figured I would patch the existing impl slightly in the meantime.
This fixes an issue where weren't actually transmitting the correct length of data, as well as adding options to allow users to configure the baud rate and enable loopback mode.