814: Extract setting of lora modulation params r=lulf a=danbev
This commit suggests extracting the lora modulation parameters into a
separate function which can then be called from both the do_tx, and
the do_rx functions.
Co-authored-by: Daniel Bevenius <daniel.bevenius@gmail.com>
This commit suggests extracting the lora modulation parameters into a
separate function which can then be called from both the do_tx, and
the do_rx functions.
811: Sync subghz peripheral support with stm32wlxx-hal r=lulf a=lulf
* A few more registers exposed
* Fix for "sleeping"
* Updating comments
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
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`.
807: Rename channel to mpmc r=huntc a=huntc
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.
Co-authored-by: huntc <huntchr@gmail.com>
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
797: Use correct index and bank for stm32 flash r=Dirbaio a=lulf
The page index was wrong because it doesn't take FLASH_BASE into account.
For l4, the page index register also depends on a bank selection register.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
709: embassy-usb stm32 r=Dirbaio a=Dirbaio
TODO
- [x] Add cfgs for EP_COUNT, EP_MEMORY_ADDR. -- ended up doing it in stm32-data
- [x] Auto-enable PWR USV in stm32l5,
- [x] Auto-enable PWR on other families that need it -- didn't find any
- [ ] ~~Assert at runtime that RCC has valid 48Mhz clock?~~ -- won't do it yet, too messy without rcc cleanup
- [x] Tested on STM32L5
- [x] Tested on STM32F303ZE
- [x] Tested on STM32F103c8
- [x] Fix duplicated irqs on STM32F303 in stm32data, remove workaround in embassy-stm32
- [x] Test HID example
- [x] Test NCM example
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
792: Add example for using a Signal. r=Dirbaio a=hydra
I didn't find an example, so I created one for the STM32H7. Code based on the nrf mutex.rs example.
794: Fix F1 compilation by implementig AF pullup r=Dirbaio a=chemicstry
Embassy fails to compile on `STM32F103RET6`, because `set_as_af_pull` function is missing for GPIOv1:
```
error[E0599]: no method named `set_as_af_pull` found for mutable reference `&mut CLK` in the current scope
--> C:\Users\chemi\.cargo\git\checkouts\embassy-0cff10c9b9902273\46473ae\embassy-stm32\src\sdmmc\mod.rs:1390:21
|
1390 | clk_pin.set_as_af_pull(clk_pin.af_num(), AFType::OutputPushPull, Pull::None);
| ^^^^^^^^^^^^^^ method not found in `&mut CLK`
```
GPIOv1 actually supports pullups in AF mode, but only for inputs. The `sdmmc` driver, which was causing compile errors uses pullups for push-pull outputs and this will silently fail. But IMO not adding pullups to sdmmc interface is a hardware design problem, not HAL.
Co-authored-by: Dominic Clifton <me@dominicclifton.name>
Co-authored-by: chemicstry <chemicstry@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
* Update copyright holder names
Fixes#472
* Add notice file to clarify copyright ownership
The NOTICE file declares that copyright is owned by the individuals
contributing to Embassy, and that all contributed work is licensed under
Apache-2.0 or MIT.
784: stm32: make tick rate configurable r=Dirbaio a=willglynn
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`.
Additionally, `embassy/time` now functions in the absence of any `embassy/time-tick-*` feature, defaulting to 32768 Hz if left unspecified.
Co-authored-by: Will Glynn <will@willglynn.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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.
788: Misc USB improvements, for stm32 r=Dirbaio a=Dirbaio
See individual commit messages.
These changes help implementing the driver for STM32 USBD (#709)
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
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>
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
783: Reimplement BufRead for BufferedUart r=Dirbaio a=chemicstry
The `AsyncBufRead` implementation for `BufferedUart` was removed in https://github.com/embassy-rs/embassy/pull/752, this PR reimplements it from `embedded-io`. This allows reading `BufferedUart` without copying slices.
Co-authored-by: chemicstry <chemicstry@gmail.com>
