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>
1025: Implement I2C timeouts, second attempt r=Dirbaio a=chemicstry
This is an alterrnative to #1022 as discussed there.
Timeouts are implemented using suggested `check_timeout: impl Fn() -> Result<(), Error>` function, which does not depend on `embassy-time` by default and is a noop for regular I2C.
This also adds `time` feature like in `embassy-nrf` to enable `embassy-time` dependencies. While at it, I also gated some other peripherals that depend on `embassy-time`, notably `usb` and (partially) `subghz`.
`TimeoutI2c` is currently only implemented for i2cv1, because i2cv2 has additional complications:
- Async methods still use a lot of busy waiting code in between DMA transfers, so simple `with_timeout()` will not work and it will have to use both types of timeouts. It could probably be rewritten to replace busy waits with IRQs, but that's outside the scope of this PR.
- I2C definition `I2c<'d, T, TXDMA, RXDMA>` is different from i2cv1 `I2c<'d, T>` making it hard to share single `TimeoutI2c` wrapper. A couple of options here:
- Duplicate `TimeoutI2c` code
- Add dummy `TXDMA`, `RXDMA` types to i2cv1 considering that in the future it should also support DMA
Co-authored-by: chemicstry <chemicstry@gmail.com>
959: Generic, executor-agnostic queue implementation r=ivmarkov a=ivmarkov
Hopefully relatively well documented.
Implementation relies on a fixed-size `SortedLinkedList` from `heapless`. (By default, for up to 128 timer schedules, but we can lower this number to - say - 64.)
As discussed earlier, on queue overflow, the `WakerRegistration` approach is utilized, whereas the waker that is ordered first in the queue is awoken to make room for the incoming one (which might be the waker that would be awoken after all!). Wakers are compared with `Waker::will_wake`, so the queue should actually not fill up that easily, if at all.
I've left provisions for the user to manually instantiate the queue using a dedicated macro - `generic_queue!` so that users willing to adjust the queue size, or users (like me) who have to use the queue in a complex "on-top-of-RTOS-but-the-timer-driver-calling-back-from-ISR" scenario can customize the mutex that protects the queue.
The one thing I'm not completely happy with is the need to call `{ embassy_time::queue::initialize() }` early on before any futures using embassy-time are polled, which is currently on the shoulders of the user. I'm open to any ideas where we can get rid of this and do it on the first call to `_embassy_time_schedule_wake`, without introducing very complex combinations of critical sections, atomics and whatnot.
Co-authored-by: ivmarkov <ivan.markov@gmail.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
1031: stm32: Add support for read_until_idle on UART - rebase r=Dirbaio a=Dirbaio
`@guillaume-michel` I rebased #1011 for you and then noticed you don't have the "allowed maintainers to push" option so I had to open a new PR.
bors r+
Co-authored-by: Guillaume MICHEL <guillaume@squaremind.io>
