STM32 SDMMC multiple block read/write support

[ost-ing]

Hello, I have added multiple block read and write support for the STM32 SDMMC peripheral.

This essentially adds CMD18 (multiple block read), CMD25 (multiple block write) and CMD12 (stop transmission) and sets the transfer up correctly.

I've tested this on SDMMCv2 devices.

I've also updated the block_device_driver implementation so it now supports multiple block read/writes. I also believe there is a preexisting issue that the block_address does not take into consideration the partition start offset, but I'll wait for confirmation from someone before modifying that.

Please let me know what you think as this PR greatly improves the read/write speeds, I would love to see it merged asap.

Kind regards

[Dirbaio]

can you fix CI?

[Dirbaio]

@ost-ing if you want this merged, CI must be green.

To fix the rustfmt job, do cargo +nightly fmt.
To fix the build job, look at the output and fix the compiler errors. At the bottom of the job it tells you for which chip it's failing in case you want to reproduce it locally, in this case it's stm32f446re.

If you need help with anything please ask!

[ost-ing]

Thanks Dirbaio, been quite busy, will look into it in the next couple of daysOn 23. Feb 2025, at 22:49, Dario Nieuwenhuis ***@***.***> wrote: @ost-ing if you want this merged, CI must be green. To fix the rustfmt job, do cargo +nightly fmt. To fix the build job, look at the output and fix the compiler errors. At the bottom of the job it tells you for which chip it's failing in case you want to reproduce it locally, in this case it's stm32f446re. If you need help with anything please ask!—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***> Dirbaio left a comment (embassy-rs/embassy#3843) @ost-ing if you want this merged, CI must be green. To fix the rustfmt job, do cargo +nightly fmt. To fix the build job, look at the output and fix the compiler errors. At the bottom of the job it tells you for which chip it's failing in case you want to reproduce it locally, in this case it's stm32f446re. If you need help with anything please ask! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[ost-ing]

@Dirbaio I've fixed the pipeline

[bluespider42]

I have been using almost the same code in my own project (STM32F411) for a while now (only the write_blocks function) without issue.

@ost-ing sorry for hijacking the pull request but I was hoping that some one with more knowledge than me might have some thoughts on this issue, as it's the main obstacle to sustained non-blocking SD operations.
#3540

[ost-ing]

I have been using almost the same code in my own project (STM32F411) for a while now (only the write_blocks function) without issue.

@ost-ing sorry for hijacking the pull request but I was hoping that some one with more knowledge than me might have some thoughts on this issue, as it's the main obstacle to sustained non-blocking SD operations. #3540

I've replied in the issue directly.

@Dirbaio Please let me know if there is anything else, I would like this merged soon if possible. Thanks!

[Dirbaio]

rebased it for you.

thanks for the PR :)

[ost-ing]

rebased it for you.

thanks for the PR :)

Thanks!