!WqsLCItsZbJGhRjnxP:matrix.org

stm32-rs

279 Members
Discussion and support for stm32-rs projects. History is publicly viewable. Bridged to #stm32-rs on Libera IRC. Code of conduct: https://www.rust-lang.org/conduct.html. Public logs: https://libera.irclog.whitequark.org/stm32-rs30 Servers

Load older messages


SenderMessageTime
25 Sep 2022
@firefrommoonlight:matrix.orgfirefrommoonlightI've been thinking about this for a while, but the timer chat here motivated me22:47:50
@firefrommoonlight:matrix.orgfirefrommoonlight
In reply to @adamgreig:matrix.org
having dma write the config should work too of course but getting the interleaving right seems tricky
Yea - I plan to do the cfg changes manually, with the DMA for handling the measuring, so as a CPU call isn't needed between each pulse, but is between each set
22:58:06
@adamgreig:matrix.orgadamgreigah, so it's a set of sent pulses, then a set of received pulses?23:00:03
@adamgreig:matrix.orgadamgreigoh, a set of sent pulses and then just one received?23:00:22
26 Sep 2022
@firefrommoonlight:matrix.orgfirefrommoonlightYep! Sent ones work. I haven't attempted received yet (it's optional, but nice)05:41:26
@firefrommoonlight:matrix.orgfirefrommoonlight*set of recieved05:41:39
@ajvvd:matrix.orgajvvd joined the room.23:57:25
28 Sep 2022
@cypherpunks0x:matrix.orgCypherpunks0x #Cypherpunks0x:matrix.org joined the room.00:29:36
@cypherpunks0x:matrix.orgCypherpunks0x #Cypherpunks0x:matrix.org joined the room.00:56:46
@762spr:matrix.org762sprI have a SPI sensor that I need to constantly take readings from with DMA. The sensor expects CS to toggle between readings (If CS is kept low, the data in the sensor's buffer is frozen and only refreshes when CS goes high (idle)) So I don't have my DMA running in circular mode, it just fires once, then in the ISR, it clears the TC flag, sets CS high, and calls my spi_dma_read function again. However, my ISR is never called a second time. I am following the example here: https://github.com/David-OConnor/stm32-hal/blob/main/examples/spi_imu_filtered.rs And I see on lines 440 and 441 he calls dma.stop and spi.stop_dma. I have omitted this because I don't want to shut down the DMA, I simply want to restart it. Is there an equivalent "reset" function that I am missing? Thanks!01:19:37
@762spr:matrix.org762spr
pub fn read_angle_dma(spi: &mut Spi<SPI1>, cs: &mut Pin, dma: &mut Dma<DMA1>) {
        defmt::info!("reading angle (fn)...");
        let write_buf = [0, 0];

        cs.set_low();

        unsafe {
            spi.transfer_dma(
                &write_buf,
                &mut crate::ANGLE,
                DmaChannel::C1,
                DmaChannel::C2,
                Default::default(), // TODO do these need to be adjusted?
                Default::default(),
                dma,
            );
        }
    }
01:20:59
@762spr:matrix.org762spr

Figured it out... Needed to set circular mode to on for the write buf. I assumed the address would be cleared/reset when the DMA was reconfigured on each spi.transfer_dma, but I guess that's not the case. I also am using the stop functions now, like in the example because that all gets undone in the transfer function.

pub fn read_angle_dma(spi: &mut Spi<SPI1>, cs: &mut Pin, dma: &mut Dma<DMA1>) {
        //defmt::info!("reading angle (fn)...");
        let write_buf = [0, 0];
        cs.set_low();

        let cfg1 = ChannelCfg {
            priority: Priority::VeryHigh,
            circular: Circular::Enabled,
            periph_incr: IncrMode::Disabled,
            mem_incr: IncrMode::Enabled,
        };
        let cfg2 = ChannelCfg {
            priority: Priority::VeryHigh,
            circular: Circular::Disabled,
            periph_incr: IncrMode::Disabled,
            mem_incr: IncrMode::Enabled,
        };

        unsafe {
            spi.transfer_dma(
                &write_buf,
                &mut crate::ANGLE,
                DmaChannel::C1,
                DmaChannel::C2,
                cfg1,
                cfg2,
                dma,
            );
        }
    }
05:01:40
@firefrommoonlight:matrix.orgfirefrommoonlight
In reply to @762spr:matrix.org

I have a SPI sensor that I need to constantly take readings from with DMA. The sensor expects CS to toggle between readings (If CS is kept low, the data in the sensor's buffer is frozen and only refreshes when CS goes high (idle))

So I don't have my DMA running in circular mode, it just fires once, then in the ISR, it clears the TC flag, sets CS high, and calls my spi_dma_read function again.

However, my ISR is never called a second time. I am following the example here:
https://github.com/David-OConnor/stm32-hal/blob/main/examples/spi_imu_filtered.rs
And I see on lines 440 and 441 he calls dma.stop and spi.stop_dma. I have omitted this because I don't want to shut down the DMA, I simply want to restart it. Is there an equivalent "reset" function that I am missing?

Thanks!

Those lines are required per the RM
05:52:05
@firefrommoonlight:matrix.orgfirefrommoonlight* Those lines are required per the RM. Possible it would work without, but I haven't tried05:52:41
@762spr:matrix.org762spr
In reply to @firefrommoonlight:matrix.org
Those lines are required per the RM. Possible it would work without, but I haven't tried
Yeah I ended up uncommenting them after going through the HAL2 code and finding out they were being re enabled in spi.transfer_DMA. I was mistakingly thinking they were causing the problem but it was the write buffer.
06:02:14
@firefrommoonlight:matrix.orgfirefrommoonlightSweet; glad it's working06:19:56
@firefrommoonlight:matrix.orgfirefrommoonlightRedacted or Malformed Event08:33:14
@firefrommoonlight:matrix.orgfirefrommoonlight * Btw, there's a potential trap in the code you posted: The write buf might be dropped before the write xfer is complete. Maybe doesn't come up since it's just 2 bytes, but you can dodge this by managing the lifetime. (Most easily by using a STATIC buffer. 08:33:31
@firefrommoonlight:matrix.orgfirefrommoonlightThere's a potential trap in that example and what you posted I just noticed - the write buffer might go out of scope before the write is complete08:34:34
@firefrommoonlight:matrix.orgfirefrommoonlight Can dodge this by making it a STATIC 08:34:43
@762spr:matrix.org762sprGood point. Thanks!08:54:04
@udayakumarshidakal:matrix.orgUdayakumar Hidakal Hello All,
We are working on rust based driver development for STSAFE-A100. we couldn't find any reference manual for the same, Is there any NDA? If not could any one share resources
required for driver development in rust?
09:19:59
@chemicstry:matrix.orgchemicstry
In reply to @udayakumarshidakal:matrix.org
Hello All,
We are working on rust based driver development for STSAFE-A100. we couldn't find any reference manual for the same, Is there any NDA? If not could any one share resources
required for driver development in rust?
It seems that they have driver sources in https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-safea1.html you could use that
11:37:37
@ryan-summers:matrix.orgryan-summersI also was able to see a datasheet on ST's website that outlined how to use the device14:41:50
@lpower:swordfish.engineeringlpower joined the room.18:32:59
29 Sep 2022
@udayakumarshidakal:matrix.orgUdayakumar Hidakal
In reply to @chemicstry:matrix.org
It seems that they have driver sources in https://www.st.com/content/st_com/en/products/embedded-software/mcu-mpu-embedded-software/stm32-embedded-software/stm32cube-expansion-packages/x-cube-safea1.html you could use that
This make sense, thank you for this information chemicstry .
03:16:03
@cypherpunks0x:matrix.orgCypherpunks0x #Cypherpunks0x:matrix.org left the room.10:37:27
2 Oct 2022
@tumler:matrix.orgtumler joined the room.21:27:33
5 Oct 2022
@hans_sanitizer:matrix.orghans_sanitizer joined the room.17:33:14
6 Oct 2022
@unrelentingtech:mozilla.orgunrelentingtech left the room.22:15:58

There are no newer messages yet.


Back to Room List