1046: embassy-stm32: Fix bug when Uart::read future is dropped and DMA request was not stopped r=lulf a=guillaume-michel
fixes#1045
regression was introduced with PR #1031
Co-authored-by: Guillaume MICHEL <guillaume@squaremind.io>
1039: stm32-metapac-gen: Use `serde_json` to parse json files r=Dirbaio a=GrantM11235
This makes stm32-metapac-gen over twice as fast. A full run on my desktop goes from about six and a half seconds to about three seconds. Suprisingly, it also reduces the fresh compile time by almost a second.
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1037: Add uart async task example r=miathedev a=miathedev
Dear Embassy Team,
here i propose an additional async uart pass-through example for the STM32WL.
Because im quite new to Rust, is there something like **interfaces**?
The code:
```
mut usart1: Uart<
'static,
embassy_stm32::peripherals::USART1,
embassy_stm32::peripherals::DMA1_CH3,
embassy_stm32::peripherals::DMA1_CH4,
>,
mut usart2: Uart<
'static,
embassy_stm32::peripherals::LPUART1,
embassy_stm32::peripherals::DMA1_CH5,
embassy_stm32::peripherals::DMA1_CH6,
>,
```
is quite ugly in my opinion. I would like to allow any Type of DMA and USART/UART as argument. Is this possible somehow?
Im open to any feedback.
With love,
Mia
Co-authored-by: miathedev <mia@metzler.systems>
951: (embassy-rp): Implementation of generic flash mutation access r=Dirbaio a=MathiasKoch
I have attempted to utilize the work done in `rp2040-flash` by implementing `embedded-storage` traits on top, for RP2040.
Concerns:
1. ~~Should the DMA be paused where I have put a FIXME note? `DMA_CHx.ctrl_trig().write(|w| { w.set_en(false) })`? If so, how to properly do that without have control over the peripheral for the DMA channels? And if so, I assume we should only re-enable/unpause the ones that were enabled before?~~
2. ~~Should I make sure core2 is halted as part of this code? I am not sure if ea8ab1ac80/examples/flash_example.rs (L103-L109) is heavy/slow code to run?~~
3. ~~Any good way of making this configurable over `FLASH_SIZE`, `WRITE_SIZE` and `ERASE_SIZE` without doing it as generics or parameters, as those make it possible to do differing configs throughout the same program, which feels wrong? Preferably, a compile-time option?~~
**EDIT:**
I have implemented the flash API here under the assumption that all external QSPI nor flashes are infact `Multiwrite` capable, as this makes it possible to use the ROM function for writes of 1 bytes at a time.
I have also added a HIL test for this, but because HIL tests are running 100% from RAM and I wanted to make sure it still works when running from flash, I have also added an example testing erase/write cycles of entire sectors, as well as single bytes in multi-write style.
Ping `@Dirbaio`
Co-authored-by: Mathias <mk@blackbird.online>
Co-authored-by: Vincent Stakenburg <v.stakenburg@sinewave.nl>
Co-authored-by: Joakim Hulthe <joakim@hulthe.net>
Co-authored-by: Alex Martens <alex@thinglab.org>
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1034: stm32/usart: Fix bug where USART idle flag could end a `read` prematuraly r=Dirbaio a=guillaume-michel
on STM32, when setting USART `detect_previous_overrun = true`, the idle flag is not cleared and could result in premature end of the `read` method.
This PR fixes that.
Co-authored-by: Guillaume MICHEL <guillaume@squaremind.io>
1033: stm32/usart: Add missing constructor with hardware flow control r=Dirbaio a=guillaume-michel
This PR follows #1031 and #987 and add missing constructors with hardware flow control.
It also factor general UART configuration like word size, parity, ... used in `Uart`, `UartRx`, `UartTx` and `BufferedUart`.
Co-authored-by: Guillaume MICHEL <guillaume@squaremind.io>
1032: stm32/adc: Misc refactoring r=Dirbaio a=GrantM11235
Noteworthy changes:
- Fixed a few typos in the `SampleTime`s
- `set_resolution` now writes directly to the configuration register. This also fixed a bug in v3 where the resolution was changed while `ADEN` is enabled, which the datasheet says isn't allowed.
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1024: stm32/adc: Remove voltage and temperature conversions r=Dirbaio a=GrantM11235
The current conversion utilities are confusing and a bit of a footgun. (Two out of the three examples got it wrong! They didn't measure vref at all, so all the conversions are completely wrong if vcca isn't 3.3v)
I think we should eventually have some sort of conversion utilities in the HAL, but for now I think it is best to just remove it and let the users do their own math.
cc `@chemicstry`
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
