613: Rust stable support r=Dirbaio a=Dirbaio
This PR adds (limited) stable Rust support!
The drawbacks are:
- No `#[embassy::task]`, `#[embassy::main]`. (requires `type_alias_impl_trait`). You have to manually allocate the tasks somewhere they'll live forever. See [example](https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/raw_spawn.rs)
- No async trait impls (requires GATs). Note that the full API surface of HALs is still available through inherent methods: #552#581
- Some stuff is not constructible in const (requires `const_fn_trait_bound`), although there's an (ugly) workaround for the generic `Mutex`.
So it's not that bad in the end, it's fully usable for shipping production-ready firmwares. We'll still recommend nightly as the default, until GATs and `type_alias_impl_trait` are stable.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
607: stm32: Add standard crate-wide macros for pin/dma traits r=Dirbaio a=Dirbaio
All drivers will declare the traits using these macros.
This has a few implications:
- ALL drivers will have an Instance trait, even for drivers that usually have only one instance (for example crc, eth)
- It's no longer possible to have a fn configure() in pin traits, drivers will have to do that some other way
In the future, build.rs will generate all the impls instead of macrotables.
Pin/Dma traits are no longer explicitly sealed, since gpio::Pin and dma::Channel are already sealed, which has the same effect. This means the `af_num()` and `request()` funcs are now public, but IMO that's okay, they're unlikely to change.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
612: Add button_events example for stm32f3 r=Dirbaio a=ceigel
This is a more elaborate example of using buttons and leds.
Tested on STM32F3DISCOVERY
Co-authored-by: Cristian Eigel <cristian.eigel@esrlabs.com>
Add an example documenting the config param based on help I got in the matrix chat.
Because the example is very short and incompatible with the other example code I just included it inline.
610: Update cargo-batch. r=Dirbaio a=Dirbaio
Cargo-batch now prints target+features when buildng a crate fails, which is very handy when one of the 30 `embassy-stm32`s fails in CI.
Before:
```
error: could not compile embassy-stm32 due to 2 previous errors
```
After:
```
error: could not compile `embassy-stm32` due to 2 previous errors
target: Target(CompileTarget { name: "thumbv7em-none-eabi" })
features: ["_time-driver", "defmt", "exti", "stm32f410tb", "time-driver-any"]
```
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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>
