stm32-rs / bxcan Goto Github PK

This does seem to work (though I haven't yet sent a message):

    dp.RCC.apb2enr.write(|w| w.syscfgen().enabled());

    let gpioa = dp.GPIOA.split();
    let gpiob = dp.GPIOB.split();
    let gpioc = dp.GPIOC.split();
    let mut rcc = dp.RCC.constrain();

    let clocks = rcc
        .cfgr
        .use_hse(16.mhz())
        .sysclk(48.mhz())
        .pclk1(24.mhz())
        .freeze();

    let mut delay = Delay::new(cp.SYST, clocks);

    CAN1::enable(&mut rcc.apb1);

    dp.CAN1.mcr.modify(|_, w| w.sleep().clear_bit());
    let mut waiting = true;
    while waiting {
        let msr = dp.CAN1.msr.read();
        if msr.slak().bit_is_set() {
            waiting = false;
        }
    }

    dp.CAN1.mcr.modify(|_, w| w.dbf().clear_bit());

    let r_mcr = dp.CAN1.mcr.read().bits();
    let r_msr = dp.CAN1.msr.read().bits();
    let r_tsr = dp.CAN1.tsr.read().bits();

    /* request initializiation */
    dp.CAN1.mcr.modify(|_, w| w.inrq().set_bit());
    let mut waiting = true;
    while waiting {
        let msr = dp.CAN1.msr.read();
        if msr.inak().bit_is_set() {
            waiting = false;
        }
    }

    dp.CAN1.btr.modify(|_, w| unsafe { w.bits(0x001c_0003) });

compare to the initialization process in this pacakge

        can.mcr
            .modify(|_, w| w.sleep().clear_bit().inrq().set_bit());
        while can.msr.read().inak().bit_is_clear() {}

        can.mcr
            .modify(|_, w| w.sleep().set_bit().inrq().clear_bit());
        while can.msr.read().slak().bit_is_clear() {}

        let msr = can.msr.read();
        while !msr.slak().bit_is_set() {
            can.mcr
                .modify(|_, w| w.abom().set_bit().sleep().clear_bit());
        }

I'm not sure why it's currently done this way, but the slak() bit is not set.

@jonas-schievink Can you put out a new release with the defmt update? thanks.

Problem while executing the example file can-send.rs from the stm32f4xx_hal crate [https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/can-send.rs] for stm32f429 Discovery board, cannot find any way to instantiate can using new(), the compiler shows error saying there is no such function like new().
I have been facing this issue since a while. It would be great if you could help.

Does bxcan implement futures for embassy.
How can I use .await with can.receive().await?

The condition here:

Should this be reversed to be && id > IdReg::from_register(tir.bits()) so it only returns WouldBlock in the case that the requested id is higher (lower priority) than the existing pending frame?

embedded-can is a public dependency at version 0.x, so it prevents bxcan to be published at 1.0 according to the API guidelines.

transmit should return an opaque object that indicates not only which frame was dequeued, but also which mailbox the new frame was put into.

Currently (after #37), users have to perform 2 steps to use bxCAN: Call Can::new, then call Can::modify_config. The rest is very hard to forget because of #[must_use] on CanConfig.

We could reduce this to 1 step by replacing Can::new by Can::builder, and have that return a CanBuilder that functions similar to CanConfig, but gives you a Can instance when finished.

Hi,

I'm trying to understand the state of affairs with embedded-can but I'm having a hard time figuring it out. Can anyone shed some light?

Note that I've also created an issue in the embedded rust WG

Thanks,

In the case I understood the API correctly, it is currently not possible to retrieve the peripheral consumed with Can::new associated with the Instance trait

To retrieve the peripheral, maybe a free() method should be implemented like that:

diff --git a/src/lib.rs b/src/lib.rs
index 2584107..f589e00 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -470,6 +470,10 @@ where
     pub fn split(self) -> (Tx<I>, Rx<I>) {
         unsafe { (Tx::conjure(), Rx::conjure()) }
     }
+
+    pub fn free(self) ->  I {
+        self.instance
+    }
 }
 
 impl<I: FilterOwner> Can<I> {

This is probably not enough, I guess. I have only glanced over the implementation, but I imagine, that the peripheral has to be deconfigured to safely free it.

Is there a way to configure the FIFO assignment of a filter? From the datasheet, it's configured using the CAN_FFAxR register and I don't see any references to that register in the source for this.

I am building some things that work with multiple device crates and have just started getting cargo update errors because one crate has update bxcan while another has not:

error: failed to select a version for `defmt`.
    ... required by package `bxcan v0.5.0`
    ... which is depended on by `stm32f7xx-hal v0.2.0 (https://github.com/stm32-rs/stm32f7xx-hal#c0bb1f2b)`
    ... which is depended on by `eg_stm_hal v0.1.0 (/home/paul/githubClones/eg_stm_hal/boards/none-stm32f722)`
versions that meet the requirements `^0.2.0` are: 0.2.1, 0.2.0

the package `defmt` links to the native library `defmt`, but it conflicts with a previous package which links to `defmt` as well:
package `defmt v0.1.3`
    ... which is depended on by `bxcan v0.4.0`
    ... which is depended on by `stm32f0xx-hal v0.17.1 (https://github.com/stm32-rs/stm32f0xx-hal#e9c99650)`
    ... which is depended on by `eg_stm_hal v0.1.0 (/home/paul/githubClones/eg_stm_hal/boards/none-stm32f722)`

failed to select a version for `defmt` which could resolve this conflict

It seems that bxcan demands a specific version of defmt and also in the README.md usage suggests demanding a specific version of bxcan (now bxcan = "0.5.0" but I see it is updated automatically).

Any chance you can be more flexible by depending on defmt = "^..." or ">=..." and suggest similar flexibility regarding bxcan in your README?

They both enter an 'initialization mode', though I think the modes are different. I could add a new method called modify_config that would allow method chaining, like the filter configuration. This would be a non-breaking change for almost all projects.

hi, i was wondering what is the current status and if there are any plans to update to embedded-can traits? i am happy to be of any help.

Basically the title. I believe that if this is available only on STM32s and the HALs will become dependent on it, it might be a good idea to be maintained as part of the organization.

What do you think about it? This is just an idea I had when reviewing a PR that was adding the dependency, I certainly don't want to force you to move the repository there.

I’m in the process of porting this to stm32f1xx devices with two CAN instances.

With the current API its easy to forget to enable filters especially when only using CAN2.
I propose following API to ensure filters are configured:

// Single intsance
let filters = can
    .filters()
    .bank(…)
    .bank(…)
    .enable(); // Clears the FINIT bit

// Multiple intsances
let (can1_filters, can2_filters) = can1
    .filters()
    .bank(…)
    .bank(…)
    .slave_filters()
    .bank(…)
    .bank(…)
    .enable(); // Clears the FINIT bit

// Require the filters so the user does not forget to set them up and
// starts debugging because no messages are received at all.
can1.enable(can1_filters);
can2.enable(can2_filters);

What do you think? Any pitfalls I overlooked?

The latter is newer and allows method chaining

Hi,

thanks for the crate, great work. However I noticed some things:

• on crates.io, this is listed as v0.5.0 and it links to another fork of this GitHub repo
• said fork is tagged only up to v0.4.0 and depends on defmt v0.1.3 and therefore breaks builds with the current recommended version of defmt, i.e. v0.2.0
• this creates dependency hell because docs of defmt, examples, etc all are geared to be compatible with defmt v0.2.0
• this GitHub repo here depends on defmt v0.2.0 already, but that is not of importance since crates.io does not link here

Is it fair to assume that this here is the active development crate? If that is the case, may you point crates.io in the right direction, please? While at it, a release for 0.5.0 could be created here as well.

I'm sorry to have to bother you with this, but I don't see how I could fix this myself.

Cheers

It's easy to forget to call it, so making it consume the CanConfig and marking that with #[must_use] makes that harder. This is a breaking change.