574: Add the possibility to reconfigure Spi mode and bit order configurati… r=matoushybl a=matoushybl
…on on the fly.
I have not tested these changes. I am also not sure if the peripheral should be disabled when changing these settings. What do you think `@Dirbaio` ?
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
572: Makes the uarte endtx event available r=Dirbaio a=huntc
This PR allows `event_endtx` to be used outside of the `Uarte` itself. As a consequence, PPI can be used to drive tasks given the end of transmission on the Uarte. This is particularly useful for situations like RS485 where a GPIO may be required to be set to high when transmitting, then cleared when done. A non-PPI approach can cause a delay in the clearing of this GPIO as other Embassy tasks might become scheduled. Not clearing the GPIO in a timely manner can be problematic.
Here's an example of our usage with this change:
```rust
let uarte_tx_enable = OutputChannel::new(
p.gpiote_ch,
Output::new(p.uarte_tx_enable_pin, Level::Low, OutputDrive::Standard),
OutputChannelPolarity::Set,
);
let mut ppi = Ppi::new_one_to_one(p.ppi_ch, uarte.event_endtx(), uarte_tx_enable.task_clr());
ppi.enable();
```
...and then later when writing:
```rust
uarte_tx_enable.set();
let _ = uarte_tx.write(&datagram_buf).await;
```
Co-authored-by: huntc <huntchr@gmail.com>
This commit allows event_endtx to be used outside of the Uarte itself. As a consequence, PPI can be used to drive tasks given the end of transmission on the Uarte. This is particularly useful for situations like RS485 where a GPIO must be set to high when transmitting then cleared when done. A non-ppi approach can cause a delay in the clearing of this GPIO as other Embassy tasks might become scheduled.
567: Remove unsafe from new on RND r=Dirbaio a=huntc
Unsafe is not required here given that all futures are required to live longer than their global peripheral instances. There are other occurrences of unsafe being used on new that should be removed. I started to do that but then went down a bit of a rabbit hole. Therefore, just confining this PR to what I'm currently exposed to.
Co-authored-by: huntc <huntchr@gmail.com>
Unsafe is not required here given that all futures are required to live longer than their global peripheral instances. There are other occurrences of unsafe being used on new that should be removed. I started to do that but then went down a bit of a rabbit hole.
539: nrf: async usb r=Dirbaio a=jacobrosenthal
Frankensteined together from this old pr https://github.com/embassy-rs/embassy/pull/115 and nrf-usdb
~Doesnt currently work..~
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
545: Add adapter for implementing async traits for blocking types r=lulf a=lulf
This allows writing drivers relying on async traits, while still
functioning with implementations that already implement the embedded-hal
traits.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
563: Initial ADC support for on STM32F1xx r=Dirbaio a=sjoerdsimons
Add an ADC implementation for F1 based chips. Primarily tested using ADC1, proper functionality for ADC2 probably needs some extra work as it's mainly a slave and can't e.g. measure vrefint by itself.
Needs https://github.com/embassy-rs/stm32-data/pull/115
Co-authored-by: Sjoerd Simons <sjoerd@collabora.com>
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
