914: (embassy-rp): Add I2C master implementation r=Dirbaio a=MathiasKoch
This PR adds both blocking and DMA based async implementations of I2C master.
Both E-H 0.2 & E-H 1.0 abstractions are implemented as well.
### Questions & concerns:
- Do we need an I2C interrupt handler (for transfer done, abort & error handling?) (async only)
- Do we need to add some automatic attempt at unblocking an I2C bus in case of failures (see ref: 7ebfd553f3/src/i2c_dma.c (L116-L142))
- Should I add `vectored_{read, write}` implementations?
Co-authored-by: Mathias <mk@blackbird.online>
Co-authored-by: Mathias Koch <mk@blackbird.online>
979: usb: make HALs depend only on embassy-usb-driver. r=Dirbaio a=Dirbaio
Follow up to #972
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
934: (embassy-rp): Add Buffered UART implementation r=MathiasKoch a=MathiasKoch
### Questions & concerns:
- ~~Would it make sense to add `RxBufferedUart` and `TxBufferedUart`, for cases where you would want to only buffer one way?~~
- ~~Do I need to be monitoring more interrupt flags than `Receive` & `Receive timeout`?~~
This PR adds working `BufferedUart` implementation, along with `RxBufferedUart` and `TxBufferedUart`. The implementation leaves room for improvement with respect to performance, as it still does not utilize DMA nor the internal UART buffers.
Co-authored-by: Mathias <mk@blackbird.online>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
973: Rework STM32 BufferedUart internals so we can split into Rx and Tx like embassy-nrf r=lulf a=guillaume-michel
Context:
On STM32, BufferedUart is not splittable into Rx and Tx part like the non buffered version. On embassy-nrf, a RefCell is used to make BufferedUarte splittable.
Description:
This PR add the possibility to split BufferedUart into Rx and Tx without adding breaking changes.
Hope somebody find it useful
Co-authored-by: Guillaume MICHEL <guillaume@squaremind.io>
977: Use firmware writer in stm32{f7, h7} example app r=lulf a=lulf
The new FirmwareWriter is useful in particular for these architectures due to the large erase sector size.
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
