Assert "tx_empty" interrupt a little early so there's time to wake up
and start refilling the fifo before it drains. This avoids stalling the
i2c bus if the tx fifo completely drains.
Simple example exercising an mcp23017 GPIO expander, configured on
RP2040 GPIOs 14+15 (i2c1) with 8 inputs and 8 outputs. Input bit 0
controls whether to display a mcp23017 register dump.
This is an interrupt-driven async i2c master implementation. It makes as
best use of the RP2040's i2c block's fifos as possible to minimize
interrupts.
It implements embedded_hal_async::i2c for easy interop.
WIP async impl
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>
