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.
Due to not requiring Unpin, it's not really possible to call it
after having polled it, you can only call it right after constructing it,
so in practice it's not very useful.
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>
