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>
559: USART DMA example for the STM32F7 r=Dirbaio a=olofwalker
This small PR adds the USART DMA write an example for the STM32F7. The example has been tested on a Nucleo-f767zi board.
Output from `DEFMT_LOG=info cargo run --bin usart_dma`
```
Running `probe-run --chip STM32F767ZITx target/thumbv7em-none-eabihf/debug/usart_dma`
(HOST) INFO flashing program (108 pages / 108.00 KiB)
(HOST) INFO success!
────────────────────────────────────────────────────────────────────────────────
0 INFO Hello World!
└─ usart_dma::__cortex_m_rt_main @ src/bin/usart_dma.rs:39
1 INFO wrote DMA
└─ usart_dma::main_task::task::{generator#0} @ src/bin/usart_dma.rs:31
```
Co-authored-by: Robert Walker <rgit@walker.st>
558: Port buffered uart to v1 stm32 hardware r=Dirbaio a=DCNick3
#526 seems to suggest that it will be rewritten for DMA support, but I am not sure how to implement it and the port was quite straightforward, so here it is. It might be immediately useful before DMA version will be implemented
Note that I have not tested this on v2 hardware
Co-authored-by: Nikita Strygin <nikita6@bk.ru>
561: stm32/dac: Fix disable_channel r=Dirbaio a=bgamari
Previously disable_channel enabled rather than disabled the requested
channel due to an apparent copy-paste error. Refactor to eliminate this
sort of issue by construction.
Co-authored-by: Ben Gamari <ben@smart-cactus.org>
Previously disable_channel enabled rather than disabled the requested
channel due to an apparent copy-paste error. Refactor to eliminate this
sort of issue by construction.
