The I2C master-write function was failing when executed immediately after an I2C read operation, requiring manual delays to function correctly. This fix introduces a check to ensure the I2C bus is free before initiating the write operation.
According to the RM0399 manual for STM32H7 chips, the BUSY bit (Bit 15 in the I2C ISR register) indicates whether a communication is in progress on the bus. The BUSY bit is set by hardware when a START condition is detected and cleared when a STOP condition is detected or when PE = 0.
This fix prevents the write operation from starting until the BUSY bit is cleared.
- Move typelevel interrupts to a special-purpose mod: `embassy_xx::interrupt::typelevel`.
- Reexport the PAC interrupt enum in `embassy_xx::interrupt`.
This has a few advantages:
- The `embassy_xx::interrupt` module is now more "standard".
- It works with `cortex-m` functions for manipulating interrupts, for example.
- It works with RTIC.
- the interrupt enum allows holding value that can be "any interrupt at runtime", this can't be done with typelevel irqs.
- When "const-generics on enums" is stable, we can remove the typelevel interrupts without disruptive changes to `embassy_xx::interrupt`.
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>
