993: rp i2c: blocking example r=Dirbaio a=jsgf
i2c example talking to mcp23017 i2c gpio expander.
Co-authored-by: Jeremy Fitzhardinge <jeremy@goop.org>
992: (embassy-stm32): remove flash lock/unlock public API from stm32 flash r=lulf a=MathiasKoch
Instead, perform the unlocking and locking automatically on erase and write operations.
This makes the `embedded-storage` abstraction actually useable in libraries, while still keeping the flash peripheral locked the majority of the time.
Co-authored-by: Mathias <mk@blackbird.online>
991: usb: remove all "Direction as u8" casts. r=Dirbaio a=Dirbaio
Alternative fix for #989 , see comment there for rationale.
bors r+
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
990: Small pubsub improvements r=Dirbaio a=diondokter
- Futures in pub & sub are now awaited instead of returned
- Added functions for reading how many messages are available
This helps people get better compiler diagnostics. For example, I forgot to call await on a future and the compiler didn't complain.
This also helps with making some decisions based on the state of the channels.
Co-authored-by: Dion Dokter <dion@tweedegolf.com>
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>
