685: Fix STM32 timer interrupt bug r=Dirbaio a=chemicstry
Previously timer overflow interrupts were not firing correctly, because Update Interrupt Enable (UIE) was not set.
The timers still worked somewhat correclty, because overflow was handled together with other interrupts.
Co-authored-by: chemicstry <chemicstry@gmail.com>
682: Convert chip name to upper case to fix rebuilds r=Dirbaio a=DCNick3
PR #665 made stm32-metapac rebuild when the chip definition was changed.
Though it used the lowercase version of the chip name as a filename which probably worked fine on windows with its case-independent filesystem, but was causing constant rebuilds on linux
Co-authored-by: Nikita Strygin <nikita6@bk.ru>
PR #665 made stm32-metapac rebuild when the chip definition was changed.
Though it used the lowercase version of the chip name as a filename
which probably worked fine on windows with its case-independent
filesystem, but was causing constant rebuilds on linux
678: Add minimal F2 family support r=Dirbaio a=Gekkio
Here's the bare minimum to support F2 family (207/217/205/215). A lot is missing in RCC (e.g. PLL support), but this is enough to have a working blinky example. The example is set up for a NUCLEO-F207ZG board which I don't have, but I've tested it on my custom board with a F215 and different pinout 😅
After looking at other RCC implementation, I noticed there's two main API styles: a "low-level" API (e.g. L0) where the `Config` struct has dividers and other low-level "knobs", and a "high-level" API (e.g. F0) where it has desired clock frequencies and the RCC implementation figures out how to achieve them. Which one is preferred? Personally I like the low-level API slightly more, because it gives you the most control and it would be easy to also provide some functions to calculate the required parameters based on desired clock frequencies.
F2 has a nasty errata: a delay or DSB instruction must be added after every RCC peripheral clock enable. I've added this workaround to build.rs, but am not sure if this is the best approach. Any comments?
I'm planning to add PLL support too once I know which kind of API is preferred. Would you prefer a separate pull request for that, or should I continue working on this one?
Co-authored-by: Joonas Javanainen <joonas.javanainen@gmail.com>
669: Add SDMMC v1 and SDIO support r=Dirbaio a=chemicstry
SDMMC v2 peripheral is an extension of SDMMC v1 (or SDIO) so I managed to reuse most of the code, with some cfg's.
Apart from small differeces in registers, the biggest change is that v2 uses internal DMA, while v1 has to use shared DMA peripheral. This makes code a bit uglier, because DMA channel for v1 has to be passed around. Not sure if it's possible to make it any cleaner.
This also adds `TransferOptions` structure to DMA, because SDMMC v1 requires setting peripheral flow control and burst transfers. Let me know if some alternative way would be prefered.
I tested this on STM32F429ZIT6 (with sd card) and STM32H745ZIT6 (with oscilloscope).
Depends on: https://github.com/embassy-rs/stm32-data/pull/130
Co-authored-by: chemicstry <chemicstry@gmail.com>
673: Inline GPIO functions r=Dirbaio a=nviennot
All GPIO functions are monomorphized (per pin). Inlining these make the ROM smaller when using opt-level="z"
Co-authored-by: Nicolas Viennot <nicolas@viennot.biz>
672: Reset peripherals on enable r=chemicstry a=chemicstry
Add reset on initialization to peripherals that did not have it before. This fixes problems when same peripheral is reinitialized at runtime multiple times.
Some exceptions:
- ADC: all ADCs share a single reset
- DCMI: does reset before enable - couldn't find anything about the order in the reference manual. Just keep it if it works?
I also fixed safety issues where global RCC registers where accessed without critical section.
Co-authored-by: chemicstry <chemicstry@gmail.com>
670: Make UART futures Send r=Dirbaio a=chemicstry
This is a quick fix to make `Uart` futures implement `Send`.
Previously they were `!Send`, because pointer to the data register was held across an await point. Simple rearrange fixes the issue.
Co-authored-by: chemicstry <chemicstry@gmail.com>
667: Remove duplicate stm32-metapac/src/common.rs with chiptool r=Dirbaio a=nviennot
There's a duplicate file common.rs with the chiptool crate. This PR makes the source of truth the one in chiptool.
This PR is a good pair with https://github.com/embassy-rs/chiptool/pull/4
Co-authored-by: Nicolas Viennot <nicolas@viennot.biz>
