add can support #246
add can support #246
Conversation
|
While the RCC interface looks completely unlike everything else, I'd argue that it is less racy than the existing implementations which just do a read-modify-write cycle in a potentially multitasked (i.e., interrupts of different priority) application. Edit: nevermind, everything else uses bitbanding for atomic access, so not racy at all. I guess this interface is probably not that great as it makes usage more complex. |
src/can.rs
Outdated
| //! | Function | Pins | | ||
| //! |----------|-------| | ||
| //! | TX | PB13 | | ||
| //! | RX | PB12 | |
There was a problem hiding this comment.
Those tables do not fully reflect the pins defined on L59.
| } | ||
| } | ||
|
|
||
| pins! { |
There was a problem hiding this comment.
Quick look at the stm32f407 datasheet shows that the CAN signals can be mapped to even more pins (for larger packages).
src/can.rs
Outdated
| Instance: Enable<Bus = APB1>, | ||
| { | ||
| /// Creates a CAN interaface. | ||
| pub fn new<P>(can: Instance, _pins: P, apb: &mut APB1) -> Can<Instance> |
There was a problem hiding this comment.
Its a common pattern to take ownership of the pins.
For CAN it might be a bit too restrictive though: stm32-rs/stm32f1xx-hal#215 (section Separate assign_pins())
src/can.rs
Outdated
| fn enable() { | ||
| unsafe { | ||
| let rcc = &(*RCC::ptr()); | ||
| bb::set(&rcc.apb2enr, $peren) |
xoviat
force-pushed
the
canbus
branch
2 times, most recently
from
76bc6c8 to
ac87594
Compare
This adds support for can with the bxcan crate. This differs slightly from the stm32f1 pull request and the stm32f7 pull request: the
Can::newmethod takes ownership of the pins, which requires the user to configure the pins correctly, and doesn't use the afio functionality, which doesn't appear to be present here.