606: Port multiprio example to stm32f3 and stm32f4 platforms r=Dirbaio a=ceigel
Example tested on stm32f303discovery and stm32f405 feather.
Co-authored-by: Cristian Eigel <cristian.eigel@esrlabs.com>
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>
604: Add embassy-boot r=lulf a=lulf
Continuation of https://github.com/embassy-rs/embassy/pull/588
Embassy-boot is a simple bootloader that works together with an application to provide firmware update capabilities with a minimal risk.
The bootloader consists of a platform-independent part, which implements the swap algorithm, and a platform-dependent part (currently only for nRF) that provides addition functionality such as watchdog timers softdevice support.
The bootloader is intended to be configurable for different flash sizes and architectures, and only requires that embedded-storage flash traits are implemented.
The nRF version can be configured programatically as a library, or using linker scripts to set the partition locations for DFU, ACTIVE and STATE
* DFU: Where the next firmware version should be written. This is used by the FirmwareUpdater
* ACTIVE: Where the current firmware version resides. Written by bootloader when swap magic is set
* STATE: Contains the bootloader magic and the copy progress. Can be 1-N pages long (depending on how much flash you have which will determine the copy progress index size
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
Embassy-boot is a simple bootloader that works together with an
application to provide firmware update capabilities with a minimal risk.
The bootloader consists of a platform-independent part, which implements
the swap algorithm, and a platform-dependent part (currently only for
nRF) that provides addition functionality such as watchdog timers
softdevice support.
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>
591: PWM WS2812B example and flexible sequence config r=Dirbaio a=huntc
I've permitted the PWM sequences to be mutated on stopping the PWM by associating them with a new `SingleSequencer` structure. This is so that we can perform effects on the LEDs (and other use-cases, I'm sure!). The example has been updated to illustrate the use of this by flashing a WS2812B LED.
There's also a `Sequencer` structure for more sophisticated PWM interactions, along with a `pwm_double_sequence` example to illustrate.
These changes should make it possible to attain all of the nRF PWM functionality available.
Co-authored-by: huntc <huntchr@gmail.com>
595: stm32f3: fix nonexistent cfg tests r=Dirbaio a=unrelentingtech
The rcc code was taken from stm32-rs which uses 'x' features, but embassy uses features with full chip names.
Add these 'x' wildcards as cfgs and use them in rcc. They will be useful for USB #580 too.
---
I don't have any F3 boards, so this is not tested. But the original cfg clearly doesn't look right…
Co-authored-by: Greg V <greg@unrelenting.technology>
The rcc code was taken from stm32-rs which uses 'x' features, but
embassy uses features with full chip names.
Add these 'x' wildcards as cfgs and use them in rcc.
They will be useful for USB too.
