1042: embassy-nrf: Add SPIS module r=Dirbaio a=kalkyl
Verified to be working on nrf9160
Co-authored-by: Henrik Alsér <henrik.alser@me.com>
Co-authored-by: Henrik Alsér <henrik.alser@ucsmindbite.se>
Co-authored-by: kalkyl <henrik.alser@me.com>
1065: embassy-nrf: Default disable UARTE (nrf9160) r=Dirbaio a=kalkyl
Uarte is enabled by default on the nrf9160, which is both bad for power consumption and renders the other "shared" peripherals unusable. This might be an SPM bug, but had the same issue with all pre-compiled SPM:s available out there, so adding this fix until we figure out.
Co-authored-by: Henrik Alsér <henrik.alser@me.com>
1057: stm32g0: Fix ADC for channels above 14 r=Dirbaio a=jaxter184
using the CHSELR register in sequence mode does not support ADC channels above 14. Also, it seems like the sequencer itself wasn't being used anyway, so I turned it off (maybe the whole block from L72..L76 could be removed?) and used a bit shift.
Co-authored-by: Jaxter Kim <jaxter.kim@elektron.se>
1060: feat: embassy-usb-logger and example for rpi pico r=Dirbaio a=lulf
* Add embassy-usb-logger which allows logging over USB for any device implementing embassy-usb
* Add example using logger for rpi pico
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
1064: Fix LoRaWAN PHY settings for SX126x driver r=Dirbaio a=jbeaurivage
While working on #1023 / #1041, I noticed that the `lorawan_device::PhyTxRx` implementation does not conform to the LoRaWAN standard, and therefore devices using this driver could never communicate with a gateway. This PR backports the changes I've made to fix the offending parameters, and I can confirm that the driver now works with LoRaWAN networks.
* Set preamble length to 8 symbols
* Set polarity to inverted for received messages
Co-authored-by: Justin Beaurivage <justin@wearableavionics.com>
1052: stm32: Fix watchdog division by zero for 256 prescaler, add watchdog … r=lulf a=matoushybl
…example for H7
The problem is that `2u8.powi(8) == 0`, which causes division by zero.
1053: Disable MMC interrupts r=lulf a=matoushybl
MMC interrupts can cause firmware hangup - refer to: https://github.com/stm32-rs/stm32h7xx-hal/issues/275 for more information
Fixes#594
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
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>
