WMT-GmbH / mcp25xx

no_std library for the MCP2510, MCP2515 and MCP25625 CAN controller chips
Apache License 2.0
4 stars 5 forks source link

Bump embedded-hal 1.0.0 #2

Closed snorkman88 closed 1 month ago

snorkman88 commented 2 months ago

Hi there, are you still maintaining this repo? Are there any plans to bump embedded-hal to 1.0.0?

dimpolo commented 2 months ago

Thanks for the reminder! I've pushed an update.

Could I ask you to test if everything works by using mcp25xx = {git = "https://github.com/WMT-GmbH/mcp25xx"} in your Cargo.toml?

If all is good I'll publish a new version :)

snorkman88 commented 2 months ago

Hey, that's great to hear! I was not sure about all the required changes on the source code since the SPI bus interface is now a bit different compared to the v0.2.7.

I have a test setup with an STM32F411 I will try as soon as I can and will keep you posted.

snorkman88 commented 2 months ago

Hi there @dimpolo , I am trying to compile the same example presented on the readme

    use stm32f4xx_hal::spi::{Mode, Phase, Polarity, Spi};
    use stm32f4xx_hal::{
        gpio::{self, Edge, Input, Output, PushPull},
        pac::TIM1,
        prelude::*,
        timer,
    };

    use embedded_can::nb::Can;
    use embedded_can::{Frame, StandardId};
    use mcp25xx::bitrates::clock_16mhz::CNF_500K_BPS;
    use mcp25xx::registers::{OperationMode, RXB0CTRL, RXM};
    use mcp25xx::{CanFrame, Config, MCP25xx};

   //GPIO init....

  // Configure Pins for SPI1 communication
  let sclk = gpioa.pa5.into_alternate::<5>();
  let miso = gpioa.pa6.into_alternate::<5>();
  let mosi = gpioa.pa7.into_alternate::<5>();
  let mut cs = gpioa.pa4.into_push_pull_output();

  let mut spi = Spi::new(
            dp.SPI1,
            (sclk, miso, mosi),
            Mode {
                polarity: Polarity::IdleLow,
                phase: Phase::CaptureOnFirstTransition,
            },
            16.MHz(),
            &clocks,
        );

    let mut mcp25xx = MCP25xx { spi };

    let config = Config::default()
        .mode(OperationMode::NormalOperation)
        .bitrate(CNF_500K_BPS)
        .receive_buffer_0(RXB0CTRL::default().with_rxm(RXM::ReceiveAny));

    mcp25xx.apply_config(&config).unwrap();

    // Send a frame
    let can_id = StandardId::new(123).unwrap();
    let data = [1, 2, 3, 4, 5, 6, 7, 8];
    let frame = CanFrame::new(can_id, &data).unwrap();
    mcp25xx.transmit(&frame).unwrap();

These two lines:

mcp25xx.apply_config(&config).unwrap();

Raises

the method apply_config exists for struct MCP25xx<Spi<SPI1>>, but its trait bounds were not satisfied the following trait bounds were not satisfied: Spi<stm32f4xx_hal::pac::SPI1>: SpiDevice spi.rs(156, 1): doesn't satisfy Spi<stm32f4xx_hal::pac::SPI1>: SpiDevice

and

mcp25xx.transmit(&frame).unwrap();

Raises

the method transmit exists for struct MCP25xx<Spi<SPI1>>, but its trait bounds were not satisfied the following trait bounds were not satisfied: Spi<stm32f4xx_hal::pac::SPI1>: SpiDevice which is required by MCP25xx<Spi<stm32f4xx_hal::pac::SPI1>>: embedded_can::nb::Can spi.rs(156, 1): doesn't satisfy Spi<stm32f4xx_hal::pac::SPI1>: SpiDevice lib.rs(71, 1): doesn't satisfy `_: Can

I am sure I missed sth important. Any help?

dimpolo commented 2 months ago

With the new embedded-hal traits you'll need to use something like https://docs.rs/embedded-hal-bus/0.2.0/embedded_hal_bus/spi/struct.ExclusiveDevice.html#method.new_no_delay to combine the spi and the cs into one struct that implements SpiDevice

snorkman88 commented 2 months ago

It's me again. This piece of code seems to work!!! 🍾

        let mut spi = Spi::new(
            dp.SPI1,
            (sclk, miso, mosi),
            Mode {
                polarity: Polarity::IdleLow,
                phase: Phase::CaptureOnFirstTransition,
            },
            16.MHz(),
            &clocks,
        );

        let exclusive_spi_device = ExclusiveDevice::new_no_delay(spi, cs);
        match exclusive_spi_device{
            Ok(bus) => {
                let mut mcp25xx = MCP25xx {spi:bus};
                let config = Config::default()
                .mode(OperationMode::NormalOperation)
                .bitrate(CNF_500K_BPS)
                .receive_buffer_0(RXB0CTRL::default().with_rxm(RXM::ReceiveAny));

                mcp25xx.apply_config(&config).unwrap();

                // Send a frame
                let can_id = StandardId::new(123).unwrap();
                let data = [1, 2, 3, 4, 5, 6, 7, 8];
                let frame = CanFrame::new(can_id, &data).unwrap();
                mcp25xx.transmit(&frame).unwrap();

            },
            Err(_) => {panic!("ERROR")}
        }

I have been able to see the packet on the bususing my MKS CANable v2.0 and SavvyCAN on my MAC M1.

Screenshot 2024-07-19 at 22 20 16

I still need to test receiving some data though.

snorkman88 commented 2 months ago

Good morning, receiving also works 🥳

Screenshot 2024-07-20 at 08 46 21

There is only one problem and it's when sending a frame with RTR set. My code is the following:

        let can_id = StandardId::new(333).unwrap();
        let frame = CanFrame::new_remote(can_id, 8).unwrap();
        mcp25xx.transmit(&frame).unwrap();

The frame does not appear on the bus.

dimpolo commented 2 months ago

That's strange, I haven't manually tested remote frame on my end before but at first glance I don't see a reason why they wouldn't work. Is there a chance that either the MKS CANable v2.0 or SavvyCAN don't register remote frame properly? Do you have a logic analyzer or scope you could attach and check?

snorkman88 commented 2 months ago

That's strange, I haven't manually tested remote frame on my end before but at first glance I don't see a reason why they wouldn't work. Is there a chance that either the MKS CANable v2.0 or SavvyCAN don't register remote frame properly? Do you have a logic analyzer or scope you could attach and check?

That is what I am trying to figure out. I want to make triple sure that the problem is the MKS CANable v2.0 USB adapter or SavvyCAN.

snorkman88 commented 2 months ago

Better late than never. I can confirm the RTR frame is also working! 🚀 The problem seems to be either MKS CANable v2.0 or SavvyCAN . I have tried with a different USB-CAN adapter from INNOMAKER and sending/receiving RTR frames work without any issue.

My test setup: IMG_1718

and the capture of the frames:

Screenshot 2024-08-02 at 17 48 34

Thanks for the patience waiting for me to test this. Everything seems to be working fine for a new release 😃

dimpolo commented 1 month ago

Thanks a lot for testing! A new version is published :)