* Remove the need for generic const expressions and use buffers provided in the flash config.
* Extend embedded-storage traits to simplify generics.
* Document all public APIs
* Add toplevel README
* Expose AlignedBuffer type for convenience.
* Update examples
Call `config()` only once at construction not with every RX and TX operation.
The Lora-E5 only supports HP mode, use that instead.
The nucleo board supports both HP and LP and should continue to work.
The Seeed Studio Lora-E5 module only has two control pins.
With the `RadioSwitch` trait the user can implement any method required
by the module/board to control the TX/RX direction of the radio frontend.
* Interrupt handler only triggers a waker:
Do the actual interrupt processing which involves SUBGHZ SPI coms in the task.
* Do not require a static state for the constructor.
* Remove unsafe from construcor.
913: (embassy-rp): Add DMA implementation r=Dirbaio a=MathiasKoch
This PR adds everything necessary to do peripheral to memory DMA & memory to memory DMA operations.
It also adds async UART read & write, powered by DMA
Co-authored-by: Mathias <mk@blackbird.online>
This fixes the WASM support which was failing due to missing
critical-section implementation. This also upgrades the bindgen
dependency and ensures that tooling works.
It was only useful for doing #[embassy_executor::main(config = "config()")]`. Now that
it's gone, it makes more sense to build the config in main directly.
896: Implement I2C pullup configuration r=lulf a=chemicstry
I wasn't sure if I should put frequency into config struct, so left it separate as in SPI periph.
Also added Copy derives to gpio types, not sure why they weren't?
Co-authored-by: chemicstry <chemicstry@gmail.com>
853: Add embedded_hal_async support for embassy-rp r=Dirbaio a=danbev
This commit adds support for embedded-hal-async to the Embassy
Raspberry PI crate.
Co-authored-by: Daniel Bevenius <daniel.bevenius@gmail.com>
858: embassy-stm32: Simplify time r=Dirbaio a=GrantM11235
- Remove unused `MilliSeconds`, `MicroSeconds`, and `NanoSeconds` types
- Remove `Bps`, `KiloHertz`, and `MegaHertz` types that were only used
for converting to `Hertz`
- Replace all instances of `impl Into<Hertz>` with `Hertz`
- Add `hz`, `khz`, and `mhz` methods to `Hertz`, as well as
free function shortcuts
- Remove `U32Ext` extension trait
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
- Remove unused `MilliSeconds`, `MicroSeconds`, and `NanoSeconds` types
- Remove `Bps`, `KiloHertz`, and `MegaHertz` types that were only used
for converting to `Hertz`
- Replace all instances of `impl Into<Hertz>` with `Hertz`
- Add `hz`, `khz`, and `mhz` methods to `Hertz`, as well as
free function shortcuts
- Remove `U32Ext` extension trait
810: Takes care of power for nRF USB devices r=Dirbaio a=huntc
Modifies the usb-serial example to illustrate how to setup USB for situations where the USB power can be detected and removed.
Gaps:
~~* No support for the nrf-softdevices as yet, although this should be possible via another constructor.~~
* No support for the nrf5340, although this should be possible via USBREG.
The change is tested and appears to work. Some notes:
* There's an existing field named self_powered as a UsbDevice field. It doesn't ever appear to get set. I'm wondering if this field is intended to signal that a device has the nRF VBUS power situation or not. I'm not presently using it.
* The new PowerDetected event is generated on the bus initially in situations where just new is used i.e. without power management, including on STM. We can therefore rely on this event always being generated.
Old description:
~~EnabledUsbDevice is a wrapper around the `UsbDevice` where its enablement is also subject to external events, such as `POWER` events for nRF. It is introduced generically to support other platforms should they also require external signaling for enablement.~~
Co-authored-by: huntc <huntchr@gmail.com>
Eliminated a signal by using a simpler trait method that returns whether VBus power is available. Also includes a UsbSupply that can be signalled for use with the nRF softdevice. Includes the requirement for waiting for power to become available.
EnabledUsbDevice is a wrapper around the UsbDevice where their enablement is also subject to external events, such as POWER events for nRF. It is introduced generically to support other platforms should they also require external signalling for enablement.
817: Added a pubsub channel implementation r=lulf a=diondokter
This is similar to Tokio's Broadcast channel, except that it doesn't allocate.
The publishers and subscribers are dynamic. They use an &dyn channel reference because it's really annoying to have to specify the mutex and const generics every time.
Do we need fully generic types as well?
Co-authored-by: Dion Dokter <diondokter@gmail.com>
Co-authored-by: Dion Dokter <dion@tweedegolf.com>
It currently contains whoever was first to write some code for the crate,
even if many more people have contributed to it later.
The field is "sort of" deprecated, it was made optional recently:
https://rust-lang.github.io/rfcs/3052-optional-authors-field.html
Due the the reasons listed there I believe removing it is better than
setting it to generic fluff like "The Embassy contributors".
806: Add embassy-cortex-m crate. r=Dirbaio a=Dirbaio
- 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`.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
- 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`.
I've renamed the channel module for the MPMC as mpmc. There was a previous debate about this, but I feel that the strategy here avoids importing `channel::channel`. The change leaves `signal::Signal`, but I think that's ok. It is all a bit subjective of course. The bottom line for me is that I really like the term mpmc - it means something to me and aligns with broader naming e.g. in Tokio.
Following the project's decision that "leak unsafe" APIs are not marked as "unsafe",
update PeripheralMutex to accept non-'static state without unsafe.
Fixes#801
781: embassy-net v2 r=Dirbaio a=Dirbaio
- No more `dyn`
- It's no longer a global singleton, you can create muliple net stacks at once.
- You can't tear them down though, the Device it still has to be `'static` due to restrictions with smoltcp's "fake GAT" in the Device trait. :(
- Removed `_embassy_rand` hack, random seed is passed on creation.
785: stm32: g0: add PLL clock source r=Dirbaio a=willglynn
STM32G0 SYSCLK can be sourced from PLLRCLK. Given that the HSI runs at 16 MHz and the HSE range is 4-48 MHz, the PLL is the only way to reach 64 MHz. This commit adds `ClockSrc::PLL`.
The PLL sources from either HSI16 or HSE, divides it by `m`, and locks its VCO to multiple `n`. It then divides the VCO by `r`, `p`, and `q` to produce up to three associated clock signals:
* PLLRCLK is one of the inputs on the SYSCLK mux. This is the main reason the user will configure the PLL, so `r` is mandatory and the output is enabled unconditionally.
* PLLPCLK is available as a clock source for the ADC and I2S peripherals, so `p` is optional and the output is conditional.
* PLLQCLK exists only on STM32G0B0xx, and exists only to feed the MCO and MCO2 peripherals, so `q` is optional and the output is conditional.
When the user specifies `ClockSrc::PLL(PllConfig)`, `rcc::init()` calls `PllConfig::init()` which initializes the PLL per [RM0454]. It disables the PLL, waits for it to stop, enables the source oscillator, configures the PLL, waits for it to lock, and then enables the appropriate outputs. `rcc::init()` then switches the clock source to PLLRCLK.
`rcc::init()` is now also resonsible for calculating and setting flash wait states. SYSCLCK < 24 MHz is fine in the reset state, but 24-48 MHz requires waiting 1 cycle and 48-64 MHz requires waiting 2 cycles. (This was likely a blocker for anyone using HSE >= 24 MHz, with or without the PLL.) Flash accesses are now automatically slowed down as needed before changing the clock source, and sped up as permitted after changing the clock source. The number of flash wait states also determines if flash prefetching will be profitable, so that is now handled automatically too.
[RM0454]: https://www.st.com/resource/en/reference_manual/rm0454-stm32g0x0-advanced-armbased-32bit-mcus-stmicroelectronics.pdf
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
Co-authored-by: Will Glynn <will@willglynn.com>
