Sequences are now passed in via the start method to avoid having to stop the PWM and restart it. Sequences continue to be constrained with the same lifetime of the Pwm object itself. The pwm_sequence example has been extended to illustrate multiple sequences being passed around.
581: stm32: expose all functionality as inherent methods. r=Dirbaio a=Dirbaio
This is the previous step to implementing both the embedded-hal 0.2 and embedded-hal 1.0 + embedded-hal-async traits.
The equivalent in nrf was done in #552
- Removes need for `unwrap` in gpio.
- Removes need for `use embedded_hal::whatever` in all cases.
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
582: Make advanced timer trait not require general purpose timer trait as … r=Dirbaio a=matoushybl
…the timers are too different.
When developing pwm driver, I originally used T: GeneralPurpose16bitTimer as it could support both GP timers and advanced timer, but advanced timer requires further modifications in registers accessible only in it (BDTR - bit AOE).
This PR makes advanced timers depend on Basic16bitTimer instead, which should hopefully improve type safety and allow for better timer drivers that can distinguish between advanced timers and general purpose ones.
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
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.
