696: Add async Mutex. r=Dirbaio a=Dirbaio
What it says on the tin :)
It allows sharing data between tasks when you want to `.await` stuff while holding it locked.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
695: Simplify Channel. r=Dirbaio a=Dirbaio
- Allow initializing in a static, without Forever.
- Remove ability to close, since in embedded enviromnents channels usually live forever and don't get closed.
- Remove MPSC restriction, it's MPMC now. Rename "mpsc" to "channel".
- `Sender` and `Receiver` are still available if you want to enforce a piece of code only has send/receive access, but are optional: you can send/receive directly into the Channel if you want.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
- Allow initializing in a static, without Forever.
- Remove ability to close, since in embedded enviromnents channels usually live forever and don't get closed.
- Remove MPSC restriction, it's MPMC now. Rename "mpsc" to "channel".
- `Sender` and `Receiver` are still available if you want to enforce a piece of code only has send/receive access, but are optional: you can send/receive directly into the Channel if you want.
693: no_std version of `futures::future::select_all` r=Dirbaio a=alexmoon
Here's a no-std compatible version of `select_all`. It's not quite as useful as the original because it requires an array of Unpin futures to be pre-constructed instead of taking an iterator (which could return `Pin<Box<_>>` in `std`). And, of course, you don't get a `Vec` of the unfinished futures returned at completion. Still, I think it's cleaner than a long cons of select calls.
I'll leave it up to you whether this is sufficiently general purpose to include in Embassy or not.
Co-authored-by: alexmoon <alex.r.moon@gmail.com>
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>
