- probe-run screwed up the last release 2 weeks ago and it's still not fixed (issue 391). Doesn't look well maintained.
- Even when it's not broken, it lags behind probe-rs-cli in new chips support because it's slow in updating probe-rs.
1392: embassy-rp : Fix for division intrinsics clashing with rp2040-hal r=Dirbaio a=peterkrull
Commit [7a682ec](7a682ec02a (diff-f121955242a67342004444b26214e5d1d591c3182dcd0fedf4329ad472cd1200)) may break compilation if also using `rp2040-hal`. It seems that the rp2040-hal does have a feature flag for [disabling intrinsics](2c9921cdc5/rp2040-hal/src/sio.rs (L323)), but I still cannot seem to compile with that enabled. Adding these flags fixes it for me.
Co-authored-by: Peter Krull <peterkrullpeter@gmail.com>
1383: embassy-boot: Add nightly flag r=Dirbaio a=sawi97
This adds "nightly" as a flag to embassy-boot and embassy-boot-nrf which gates features requiring nightly, enabled by default.
Makes it possible to build the bootloader with the stable compiler when setting `default-features=false`.
It should be straight forward to do this for stm32 and rp as well, but I am not been able to test it.
Co-authored-by: sander <sander.wittwer@dengineering.no>
Co-authored-by: sawi97 <34313578+sawi97@users.noreply.github.com>
1384: rp: optimize rom-func-cache for runtime r=Dirbaio a=pennae
storing a full function pointer initialized to a resolver trampoline lets us avoid the runtime cost of checking whether we need to do the initialization. this also slightly reduces flash usage due to a slightly more space-efficient initialization procedure.
Co-authored-by: pennae <github@quasiparticle.net>
storing a full function pointer initialized to a resolver trampoline
lets us avoid the runtime cost of checking whether we need to do the
initialization.
1370: stm32/i2c: fix races when using dma. r=Dirbaio a=xoviat
This change addresses two races:
1. It removes the `chunks_transferred` state variable that is modified inside the interrupt. Analysis of the code reveals that the only time the waker can be woken is when `chunks_transferred` is incremented. Therefore, waking is enough to signal the `poll_fn` that the `chunks_transferred` has incremented. Moving to `remaining_len` clarifies the code, since there is no need to track how many chunks are remaining.
2. It moves the start of the transfer until after the waker is registered, which could theoretically occur if the clock speed is very low, but probably never would even if this wasn't fixed.
There is another race that I noticed: between writes the waker may not yet be registered. In that case, the code would simply be stuck and the `poll_fn` would never be woken. There is no way to resolve this without broadening the scope of the analysis, and this will likely never occur.
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
