- Move Interrupt and InterruptExecutor from `embassy` to `embassy-cortex-m`.
- Move Unborrow from `embassy` to `embassy-hal-common` (nothing in `embassy` requires it anymore)
- Move PeripheralMutex from `embassy-hal-common` to `embassy-cortex-m`.
The stm32 time drivers support arbitrary tick rates but the associated
Cargo features do not. Enabling any time driver presently enables
`embassy/time-tick-32768hz`; instead, enable only `embassy/time`.
This is a breaking change: users must now choose a tick rate. The
previous behavior is available by enabling the
`embassy/time-tick-32768hz` feature, but now users may also choose
`embassy/time-tick-1000hz` or `embassy/time-tick-1mhz` instead.
The replacement is `embassy-usb`. There's a WIP driver for stm32 USBD in #709,
there's no WIP driver for stm32 USB_OTG. This means we're left without
USB_OTG support for now.
Reason for removing is I'm going to soon remove `embassy::io`, and
USB uses it. I don't want to spend time maintaining "dead" code
that is going to be removed. Volunteers welcome, either to update
old USB to the new IO, or write a USB_OTG driver fo the new USB.
* Add flash drivers for L0, L1, L4, WB and WL. Not tested for WB, but
should be similar to WL.
* Add embassy-boot-stm32 for bootloading on STM32.
* Add flash examples and bootloader examples
* Update stm32-data
601: [part 1/n] Change macrotables to build.rs codegen r=lulf a=Dirbaio
This PR replaces the "macrotables" (the macros like `stm32_data::peripherals!`) with a `const METADATA`.
Macrotables had some problems:
- Hard to debug
- Somewhat footgunny (typo the "pattern" and then nothing matches and the macro now expands to nothing, silently!)
- Limited power
- Can't count, so we had to add a [special macrotable for that](f50f3f0a73/embassy-stm32/src/dma/bdma.rs (L26)).
- Can't remove duplicates, so we had to fallback to [Rust code in build.rs](f50f3f0a73/embassy-stm32/build.rs (L105-L145))
- Can't include the results as a listto another macro, so again [build.rs](https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/build.rs#L100-L101).
They work fine for the 95% of cases, but for the remaining 5% we need Rust code in build.rs. So we might as well do everything with Rust code, so everything is consistent.
The new approach generates a `const METADATA: Metadata = Metadata { ... }` with [these structs](https://github.com/embassy-rs/embassy/blob/unmacrotablize/stm32-metapac-gen/src/assets/metadata.rs) in `stm32-metapac`. `build.rs` can then read that and generate whatever code.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
602: Add stm32 USB OTG peripherals r=Dirbaio a=chemicstry
Fixes#557. This is similar to #580, but for synopsys IP.
I could add examples to other chips, but I have no way of testing them. The F4 example is tested and working.
Co-authored-by: chemicstry <chemicstry@gmail.com>
This allows writing drivers relying on async traits, while still
functioning with implementations that already implement the embedded-hal
traits.
Add examples to stm32l4 for using this feature.
* Adds an executor for WASM runtimes based on wasm_bindgen.
* Add time driver based on JS time handling.
* Add example that can run in browser locally.
* Update to critical-section version that supports 'std' flag
Based on the HAL from stm32wl, the peripheral driver has been
modified to fit into embassy, using the embassy APIs, providing
operation of the radio peripheral.
The initial version does not offer any async APIs, but the example
shows how the radio IRQ can be used to perform async TX of the radio.
Done for /embassy-stm32 only
The new generator is in /stm32-gen-features
/stm32-metapac could/should be added too
A CI check "generated features up to date" could/should be performed
* Add IRQ-driven buffered USART implementation for STM32 v2 usart
* Implementation based on nRF UARTE, but simplified to not use DMA to
avoid complex interaction between DMA and USART.
* Implementation of AsyncBufRead and AsyncWrite traits
* Some unit tests to ring buffer
* Update polyfill version
* Update sub module to get usart IRQ fix
* Chips that have multiple cores will be exposed as chipname_corename,
i.e. stm32wl55jc_cm4
* Chips that have single cores will use the chip family as feature name
and pick the first and only core from the list
* Add support for stm32wl55 chip family
