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.
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
776: Automatically set ADC clock prescaler on v2 ADC to respect max frequency r=Dirbaio a=matoushybl
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
PLL settings remained intact because these bits are not writable when PLL is enabled,
but prescaler settings were overwritten by selecting PLL as sysclk (CFGR.SW[1:0]).
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.
743: Add PLL config support for F2 r=Dirbaio a=Gekkio
- minor changes to make the F2 RCC API a bit more flexible
- low-level PLL config with assertions based on datasheet specs. It shouldn't be very difficult to later add a "reverse API" where you pass the clocks you want to a function and it generates a `PLLConfig` struct for you
- PLL API tested on my custom board with 12 MHz HSE as source for PLL to generate max clocks for SYSCLK/AHB/APB/APB1/PLL48
- the example *should* work but is untested since I don't have the Nucleo board 😞
Co-authored-by: Joonas Javanainen <joonas.javanainen@gmail.com>
SMI Ethernet PHYs all share a common base set of registers that can do
90% of all tasks. The LAN8742 driver used some vendor-specific
registers to check link negotiation status, but the need for that was
debatable, so I migrated it to a generic driver instead, anybody who
wants extra functionality can copy it and impl their own on top of it.
This makes the configuration more flexible and closer to the underlying
configuration register structure. For example, we could use HSI for the
system clock, but use HSE to output a clock with MCO.
* 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
714: add more clock options for l4 and l5 r=Dirbaio a=ant32
- added an assert so it panics if pll48div is not 48Mhz
- added MSI as a clock source for PLL
- removed hsi48 option for MCUs mentioned in l4 rcc presentation
- copied some code from l4 to l5, but don't have a way of testing it.
Co-authored-by: Philip A Reimer <antreimer@gmail.com>
715: stm32/dac: Check proper channel r=Dirbaio a=michalsrb
Small fix. Otherwise it panics when trying to use channel 1 if channel 2 does not exist.
Co-authored-by: Michal Srb <michalsrb@gmail.com>
669: Add SDMMC v1 and SDIO support r=Dirbaio a=chemicstry
SDMMC v2 peripheral is an extension of SDMMC v1 (or SDIO) so I managed to reuse most of the code, with some cfg's.
Apart from small differeces in registers, the biggest change is that v2 uses internal DMA, while v1 has to use shared DMA peripheral. This makes code a bit uglier, because DMA channel for v1 has to be passed around. Not sure if it's possible to make it any cleaner.
This also adds `TransferOptions` structure to DMA, because SDMMC v1 requires setting peripheral flow control and burst transfers. Let me know if some alternative way would be prefered.
I tested this on STM32F429ZIT6 (with sd card) and STM32H745ZIT6 (with oscilloscope).
Depends on: https://github.com/embassy-rs/stm32-data/pull/130
Co-authored-by: chemicstry <chemicstry@gmail.com>
673: Inline GPIO functions r=Dirbaio a=nviennot
All GPIO functions are monomorphized (per pin). Inlining these make the ROM smaller when using opt-level="z"
Co-authored-by: Nicolas Viennot <nicolas@viennot.biz>
* Keeps existing API for usart, but wraps it in Tx and Rx sub-types
* Adds split() method similar to nRF for getting indepdendent TX and RX
parts
* Implements e-h traits for TX and RX types
* Add stm32h7 example
Previously, every dma interrupt handler called the same `on_irq`
function which had to check the state of every dma channel.
Now, each dma interrupt handler only calls an `on_irq` method for its
corresponding channel or channels.
Approach is similar to USB OTG.
STM32L49x and STML4Ax have CAN1 and CAN2.
All others STM32L4xx do only have CAN1.
STM32F72x and STM32F73x are the only F7 devices with only CAN1.
652: Use new stm32-data registers and fix AHB clock calculation r=Dirbaio a=msamsonoff
This is the follow-on to my PR against stm32-data that added new register enums for the G0. I have updated the G0 RCC module to use those new enums.
I have also fixed an issue with the calculation of the AHB clock rate. 32 is not available as an AHB prescaler. The sequence jumps from 16 to 64. The original bit shifting math did not account for this gap. I have replaced it with a `match` instead.
653: Fixes for rustdoc building. r=Dirbaio a=Dirbaio
Co-authored-by: Matthew W. Samsonoff <matt.samsonoff@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
The original code for calculating the AHB clock did not account for the gap in
prescaler values (32 is not an available value.) The bit shifting and math has
been replaced by a `match`.
These files end up containing chip-specific info, so they deduplicate
really badly when building docs for all 1200 chips.
The doc generator removes files starting with `_`.
* On v1 interrupts cannot be cleared individually.
Instead they are cleared implicitly by reading or writing DR (which we do now).
* Multiple error flags can be set at the same time:
Handle them all in one go intstead of re-entering the ISR for each one so that
we do not lose any error flags on v1 hardware.
* Wake when the RX buffer becomes full: This allows fast running chips to pull data
from the buffer before receiving the next byte.
608: stm32f4: add adc + example r=Dirbaio a=ain101
Example tested on stm32f407vg Discovery Board.
minimal adc: no vref, dma, complex sequence
Co-authored-by: Frederik <frederik@frederik.at>
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>
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.
545: Add adapter for implementing async traits for blocking types r=lulf a=lulf
This allows writing drivers relying on async traits, while still
functioning with implementations that already implement the embedded-hal
traits.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
563: Initial ADC support for on STM32F1xx r=Dirbaio a=sjoerdsimons
Add an ADC implementation for F1 based chips. Primarily tested using ADC1, proper functionality for ADC2 probably needs some extra work as it's mainly a slave and can't e.g. measure vrefint by itself.
Needs https://github.com/embassy-rs/stm32-data/pull/115
Co-authored-by: Sjoerd Simons <sjoerd@collabora.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
558: Port buffered uart to v1 stm32 hardware r=Dirbaio a=DCNick3
#526 seems to suggest that it will be rewritten for DMA support, but I am not sure how to implement it and the port was quite straightforward, so here it is. It might be immediately useful before DMA version will be implemented
Note that I have not tested this on v2 hardware
Co-authored-by: Nikita Strygin <nikita6@bk.ru>
Previously disable_channel enabled rather than disabled the requested
channel due to an apparent copy-paste error. Refactor to eliminate this
sort of issue by construction.
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.
540: Initial support for STM32F3 r=Dirbaio a=VasanthakumarV
The [companion PR](https://github.com/embassy-rs/stm32-data/pull/109) in `stm32-data` should be merged before this PR.
The examples were tested on an STM32F303VC MCU.
Co-authored-by: VasanthakumarV <vasanth260m12@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
`async fn`s do nothing until polled, but we want the DMA transfer to
immediately start in this case. Drivers rely on it. Some require special
orders, such as "start DMA, start SPI, then wait for DMA" which is awkward
to do without eager start.
Also use a manually-impl'd future, this allows getting rid of the "double"
Unborrow channel clone.
Different STM32 RCC peripherals have different capabilities and register
values. Define types for each RCC types inside each module to ensure
full range of capabilities for each family can be used
482: Add MCO peripheral. r=Dirbaio a=matoushybl
This PR adds an abstraction over STM32 RCC feature called MCO (Microcontroller Clock Output). The clock output can bind to several clock sources and then can be scaled using a prescaler.
Given that from the embassy ecosystem the RCC is generaly invisible to the user, the MCO was implemented as a separate peripheral bound to the pin where the clock should appear.
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
456: Fix L4 clock setup for MSI and PLL to allow RNG operation r=Dirbaio a=lulf
Example is tested on STM32L475VG.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
* 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
Source-Address-Filtering is not helping the board to receive packets.
For unknown reasons, the Receive-All is required, when in theory
it should not be required. Until we figure it out, follow the
stm32h7xx-hal example of setting RA=true.
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
