1228: stm32/sdmmc: Implement proper clock configuration r=chemicstry a=chemicstry
This implements proper clock configuration for sdmmc based on chip family, because `RccPeripheral::frequency()` is almost always incorrect. This can't be fixed in PAC, because sdmmc uses two clock domains, one for memory bus and one for sd card. `RccPeripheral::frequency()` usually returns the memory bus clock, but SDIO clock calculations need sd card domain clock. Moreover, chips have multiple clock source selection bits, which makes this even more complicated. I'm not sure if it's worth implementing all this logic in `RccPeripheral::frequency()` instead of cfg's in sdmmc.
Some chips (Lx, U5, H7) require RCC updates to expose required clocks. I didn't want to mash everything in a single PR so left a TODO comment. I also left a `T::frequency()` fallback, which seemed to work in H7 case even though the clock is most certainly incorrect.
In addition, added support for clock divider bypass for sdmmc_v1, which allows reaching a maximum clock of 48 MHz. The peripheral theoretically supports up to 50 MHz, but for that ST recommends setting pll48 frequency to 50 MHz 🤔
Co-authored-by: chemicstry <chemicstry@gmail.com>
1227: stm32/dma: fix spurious transfer complete interrupts r=Dirbaio a=pattop
DMA interrupts must be acknowledged by writing to the DMA_{L,H}IFCR
register.
Writing to the CR register is unnecessary as the channel (EN bit) is
disabled by hardware on completion of the transfer.
Co-authored-by: Patrick Oppenlander <patrick.oppenlander@gmail.com>
DMA interrupts must be acknowledged by writing to the DMA_{L,H}IFCR
register.
Writing to the CR register is unnecessary as the channel (EN bit) is
disabled by hardware on completion of the transfer.
1200: feat(stm32): Add 16 data bit fmc ctor r=Dirbaio a=rmja
This has been validated with the Is42s16400j sdram on stm32f429.
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
1199: STM32 SPI: Set clk-pin pull-up/-down to match spi clock polarity r=Dirbaio a=jr-oss
Fixes#1094
There are some proposed solutions in #1094
> Keep the DMA transaction open across calls to read/write
This may be problematic if the user changes bus settings between calls, and also the reference manual says the chip should not be placed into low power mode while SPI is enabled
As already described, this is problematic and against reference manual recommendation
> Set the CLK (and maybe MOSI) pins as pull-down on setup (or pull-up, depending on config - and this would need to be updated if the user modified the config)
This is less good than driving the pin to the correct value, but may be better than nothing
That is also my preferred solution. See below citation from reference manual.
> Document this and require users fix it themselves (add a pull-up/down resistor - or configure the pins as pull-up/pull-down before passing them into SPI setup)
Setting internal pull-up/-down won't work, because `sck.set_as_af()` will change the gpio pull mode to none: https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/src/gpio.rs#L552-L555
> Dig around in the reference manual and determine if there is a better way to start/stop a DMA transaction while keeping active control of the clock the whole time
I haven't found a better way
------
From ST reference manual RM0394 (L4)
(Same note in RM0399 (H7) / RM0038 (L1) / RM0316 /F3)):
40.4.6
Communication formats
...
The idle state of SCK must correspond to the polarity selected in the SPIx_CR1 register (by
pulling up SCK if CPOL=1 or pulling down SCK if CPOL=0).
Co-authored-by: Ralf <jr-oss@gmx.net>
RM0394:
40.4.6
Communication formats
...
The idle state of SCK must correspond to the polarity selected in the SPIx_CR1 register (by
pulling up SCK if CPOL=1 or pulling down SCK if CPOL=0).
- Rename feature to `embedded-sdmmc`.
- Move embedded-sdmmc fork repo to the embassy-rs org.
- Remove unused features in the fork
- Fix impl in embassy-stm32
- Add to CI so it doesn't break again.
1159: stm32 usb otg bug fixes r=Dirbaio a=chemicstry
This fixes a couple of usb otg bugs that surfaced with `usb_ethernet` example from nrf:
- Properly implemented `Endpoint::wait_enabled()`
- Return `EndpointError::Disabled` when neccessary in `Endpoint::write()`
Co-authored-by: chemicstry <chemicstry@gmail.com>
1082: stm32: Add basic support for DMA priority settings r=lulf a=matoushybl
This adds very basic support for specifying priority for DMA interrupts. Unfortunately, the patch now doesn't allow for specifying different priorities for DMA1/DMA2, or BDMA1/BDMA2, which I didn't know how to support.
1083: stm32: Fix H7 unaligned erase r=lulf a=matoushybl
This PR simplifies erasing sectors on the H7, which was buggy.
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
1088: stm32: Enable fifo for buffered uart r=lulf a=matoushybl
This PR enables fifo for buffered uart where it is available. This should hopfully get rid of some overrun errors. I tried it in my application where it worked, but more intensive testing is probably required.
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
1052: stm32: Fix watchdog division by zero for 256 prescaler, add watchdog … r=lulf a=matoushybl
…example for H7
The problem is that `2u8.powi(8) == 0`, which causes division by zero.
1053: Disable MMC interrupts r=lulf a=matoushybl
MMC interrupts can cause firmware hangup - refer to: https://github.com/stm32-rs/stm32h7xx-hal/issues/275 for more information
Fixes#594
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
1034: stm32/usart: Fix bug where USART idle flag could end a `read` prematuraly r=Dirbaio a=guillaume-michel
on STM32, when setting USART `detect_previous_overrun = true`, the idle flag is not cleared and could result in premature end of the `read` method.
This PR fixes that.
Co-authored-by: Guillaume MICHEL <guillaume@squaremind.io>
1024: stm32/adc: Remove voltage and temperature conversions r=Dirbaio a=GrantM11235
The current conversion utilities are confusing and a bit of a footgun. (Two out of the three examples got it wrong! They didn't measure vref at all, so all the conversions are completely wrong if vcca isn't 3.3v)
I think we should eventually have some sort of conversion utilities in the HAL, but for now I think it is best to just remove it and let the users do their own math.
cc `@chemicstry`
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1025: Implement I2C timeouts, second attempt r=Dirbaio a=chemicstry
This is an alterrnative to #1022 as discussed there.
Timeouts are implemented using suggested `check_timeout: impl Fn() -> Result<(), Error>` function, which does not depend on `embassy-time` by default and is a noop for regular I2C.
This also adds `time` feature like in `embassy-nrf` to enable `embassy-time` dependencies. While at it, I also gated some other peripherals that depend on `embassy-time`, notably `usb` and (partially) `subghz`.
`TimeoutI2c` is currently only implemented for i2cv1, because i2cv2 has additional complications:
- Async methods still use a lot of busy waiting code in between DMA transfers, so simple `with_timeout()` will not work and it will have to use both types of timeouts. It could probably be rewritten to replace busy waits with IRQs, but that's outside the scope of this PR.
- I2C definition `I2c<'d, T, TXDMA, RXDMA>` is different from i2cv1 `I2c<'d, T>` making it hard to share single `TimeoutI2c` wrapper. A couple of options here:
- Duplicate `TimeoutI2c` code
- Add dummy `TXDMA`, `RXDMA` types to i2cv1 considering that in the future it should also support DMA
Co-authored-by: chemicstry <chemicstry@gmail.com>
959: Generic, executor-agnostic queue implementation r=ivmarkov a=ivmarkov
Hopefully relatively well documented.
Implementation relies on a fixed-size `SortedLinkedList` from `heapless`. (By default, for up to 128 timer schedules, but we can lower this number to - say - 64.)
As discussed earlier, on queue overflow, the `WakerRegistration` approach is utilized, whereas the waker that is ordered first in the queue is awoken to make room for the incoming one (which might be the waker that would be awoken after all!). Wakers are compared with `Waker::will_wake`, so the queue should actually not fill up that easily, if at all.
I've left provisions for the user to manually instantiate the queue using a dedicated macro - `generic_queue!` so that users willing to adjust the queue size, or users (like me) who have to use the queue in a complex "on-top-of-RTOS-but-the-timer-driver-calling-back-from-ISR" scenario can customize the mutex that protects the queue.
The one thing I'm not completely happy with is the need to call `{ embassy_time::queue::initialize() }` early on before any futures using embassy-time are polled, which is currently on the shoulders of the user. I'm open to any ideas where we can get rid of this and do it on the first call to `_embassy_time_schedule_wake`, without introducing very complex combinations of critical sections, atomics and whatnot.
Co-authored-by: ivmarkov <ivan.markov@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
