1346: fix I2C controller problems after NACK r=Dirbaio a=Juravenator
While tinkering with I2C on a NUCLEO-H723ZG, I noticed that when trying to communicate with a non-existent device you do receive a proper NACK error, but afterwards any future communications with any device no longer works as expected.
The use case is auto-detection of devices, in this case a series of Adafruit 24LC32 I2C EEPROM boards.
On closer inspection with a logic analyzer, I observed that after the NACK, any data bytes sent out by the board to the devices are just zeros. Even though the embassy code specifies the correct data in `set_txdata` in `write_internal`. Something seems to be going wrong with the controller or buffers on the board itself.
Then I noticed what seems to be a logic error in `flush_txdr`, which is called when issuing a NACK.
After flipping the if statement, I2C communications keep working as expected after issuing a NACK.
Co-authored-by: Glenn Dirkx <glenn.dirkx@gmail.com>
1342: feat(rp): add `Wait` impl to `OutputOpenDrain` r=Dirbaio a=TheLostLambda
A while ago `OutputOpenDrain` was made to implement `InputPin`, something that allowed drivers for various one-wire protocols to be written, but it's been lacking a `Wait` implementation — something that's needed to write async versions of these drivers.
This commit also adds `get_level()` to `OutputOpenDrain`, since `is_high()` and `is_low()` were already implemented, but `get_level()` itself was missing.
Co-authored-by: Brooks J Rady <b.j.rady@gmail.com>
A while ago `OutputOpenDrain` was made to implement `InputPin`,
something that allowed drivers for various one-wire protocols to be
written, but it's been lacking a `Wait` implementation — something
that's needed to write async versions of these drivers.
This commit also adds `get_level()` to `OutputOpenDrain`, since
`is_high()` and `is_low()` were already implemented, but `get_level()`
itself was missing.
1330: stm32/pwm: add complementary pwm r=Dirbaio a=xoviat
This implements complementary PWM with dead time on many supported targets. The specific dead-time programming functions are passed through directly to the user, which is a bit ugly but the best compromise I could reach for now.
Co-authored-by: xoviat <xoviat@users.noreply.github.com>
1332: executor: Replace unsound critical sections with atomics r=Dirbaio a=GrantM11235
I couldn't figure out the correct orderings, so I just left them as SeqCst for now.
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1333: STM32: Adc V1 r=Dirbaio a=GrantM11235
Based on #947
Co-authored-by: Matthew W. Samsonoff <matt.samsonoff@gmail.com>
Co-authored-by: Grant Miller <GrantM11235@gmail.com>
1323: Add hash functions to FirmwareUpdater r=Dirbaio a=rmja
This adds support for computing any hash over the update in the dtu area by providing a closure to the hash update function.
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
The internal channels (vbat, vref, and temperature) are not real pins and do
not have the `set_as_analog` method. They must be read using the
`read_internal` method.
1297: feat(stm32): Support multiple flash regions r=Dirbaio a=rmja
This depends on https://github.com/embassy-rs/stm32-data/pull/176
This is a general overhaul of the flash module to support multiple erase sizes.
Overall this PR contains:
* Move complex sector computation to embassy-hal-common to allow for tests
* Implement `FlashRegion` trait for each available flash region
* Add Flash::into_regions() to get each region.
* Implement embedded-storage traits for each region to support different erase sizes
* Split family write operations into begin/do/end
* Protection against simultaneous writes/erases for each split region is done through a global mutex
Co-authored-by: Rasmus Melchior Jacobsen <rmja@laesoe.org>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
