486: Pwm ppi events r=Dirbaio a=jacobrosenthal
More PWM yak shaving. I was going to do some safe pwm ppi events stuff but I just dont think it fits this api design.. ppi is just very low level, im not sure how safe it will be in general
* first we should probably have borrows of handlers for ppi with lifetime of the peripheral? hal does eb4ba6ae42/nrf-hal-common/src/pwm.rs (L714-L716)
* in general having access to tasks can put the state in some configuration the api doesnt understand anymore. for `SequencePwm` ideally id hand you back either only seq_start0 or seq_start1 because youd only use one based on if your `Times` is even or odd.. but again we only know that with this api AFTER start has been called. I dont think were ready for typestates
SO I figured why not add the pwm ppi events but make them unsafe and commit this example since I started it.
Somewhat related drop IS removing the last duty cycle from the pin correctly, but stop DOES NOT..the only thing that sets the pin back is pin.conf() as far as I can tell, so I tried to document that better and got rid of stop for the `SimplePwm` again since that doesnt need it then. However its ackward we dont have a way to unset the pwm without setting a new sequence of 0s, or dropping the peripheral
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
It is basically impossible to directly convert that example to a sequence for various reasons. You cant have multiple channels on same buffer with one sequence instance for starters, also at that clock rate and max_duty 1 period is far longer than the 3ms it was using, which would require using a new max_duty and thus require regenerating the sine table which makes it not representitive of the original example anymore
455: simple_playback api from nrf sdk r=Dirbaio a=jacobrosenthal
Port of the nrf_drv_pwm_simple_playback call from the nordic sdk that allows you to set up a sequence to play across leds with no interaction necessary using the 'shorts' registers to trigger looping sequences
Co-authored-by: Jacob Rosenthal <jacobrosenthal@gmail.com>
482: Add MCO peripheral. r=Dirbaio a=matoushybl
This PR adds an abstraction over STM32 RCC feature called MCO (Microcontroller Clock Output). The clock output can bind to several clock sources and then can be scaled using a prescaler.
Given that from the embassy ecosystem the RCC is generaly invisible to the user, the MCO was implemented as a separate peripheral bound to the pin where the clock should appear.
Co-authored-by: Matous Hybl <hyblmatous@gmail.com>
Rustflags apply to ALL the crates in the graph, while we only need
them for the toplevel crate which is the only one getting linked.
Rustflags are not equal for all crates, this caused cargo to re-build the
same dependency crate multiple times uselessly. After this change, deps
are reused more, making builds faster.
Note that this only applies when sharing the target/ dir for multiple crates
in the repo which is not the default.
- Removed ConfigurableChannel and added capacity numbers to the channels
- Replaced the PPI api with a new one using the DPPI terminology (publish & subscribe)
- Updated all tasks and event registers for DPPI
456: Fix L4 clock setup for MSI and PLL to allow RNG operation r=Dirbaio a=lulf
Example is tested on STM32L475VG.
Co-authored-by: Ulf Lilleengen <lulf@redhat.com>
444: nrf: add NVMC driver. r=lulf a=Dirbaio
I haven't implemented `embassy_traits::Flash` because I want to change it to match embedded_storage, which is much better designed.
Either way, NVMC can't do async anyway, so the best we could do is implementing the async trait in a blocking way...
Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
440: Add i2c example for L4 r=Dirbaio a=lulf
Tested to work on STM32 IOT01A (STM32L475VG) board.
Co-authored-by: Ulf Lilleengen <ulf.lilleengen@gmail.com>
425: Implements continuous sampling for the nRF SAADC r=huntc a=huntc
Implements continuous sampling for the nRF SAADC and also renames `OneShot` to `Saadc`. The one-shot behaviour is retained with the `sample` method and a new `run_sampler` method is provided for efficiently (i.e. zero copying) sampler processing. A double buffer is used for continuously sampling, which is swapped appropriately.
A sample frequency is provided and will set the internal timer of the SAADC when there is just one channel being sampled. Otherwise, PPI will be used to hook up the TIMER peripheral to drive the sampling task. Two methods are provided for this: `run_task_sampler` and `run_task_sampler` with the latter available where the compiler sees that just one channel is configured. Note that we set up the PPI and timer behaviour outside of the `Saadc` for maximum flexibility.
A callback is provided to the `run_sampler` method. This is a synchronous callback that should return in a reasonably short space of time. The SAADC could stall if it does not. A reasonable practice is to perform a small amount of processing within the callback to yield a signal, perhaps via `mpsc`. In the case of `mpsc`, the `try_send` method becomes useful.
A new example has been provided to illustrate continuous sampling, along with multiple channels and external timing:
```rust
#[embassy::main]
async fn main(_spawner: Spawner, mut p: Peripherals) {
let config = Config::default();
let channel_1_config = ChannelConfig::single_ended(&mut p.P0_02);
let channel_2_config = ChannelConfig::single_ended(&mut p.P0_03);
let channel_3_config = ChannelConfig::single_ended(&mut p.P0_04);
let mut saadc = Saadc::new(
p.SAADC,
interrupt::take!(SAADC),
config,
[channel_1_config, channel_2_config, channel_3_config],
);
let mut timer = Timer::new(p.TIMER0);
timer.set_frequency(Frequency::F1MHz);
timer.cc(0).write(100); // We want to sample at 10KHz
timer.cc(0).short_compare_clear();
let mut ppi = Ppi::new(p.PPI_CH0);
ppi.set_event(timer.cc(0).event_compare());
ppi.set_task(saadc.task_sample());
ppi.enable();
timer.start();
let mut bufs = [[[0; 3]; 50]; 2];
let mut c = 0;
let mut a: i32 = 0;
saadc
.run_task_sampler(&mut bufs, move |buf| {
for b in buf {
a += b[0] as i32;
}
c += buf.len();
if c > 10000 {
a = a / c as i32;
info!("channel 1: {=i32}", a);
c = 0;
a = 0;
}
SamplerState::Sampled
})
.await;
}
```
Co-authored-by: huntc <huntchr@gmail.com>
Implements continuous sampling for the nRF SAADC and also renames `OneShot` to `Saadc`. The one-shot behaviour is retained with the `sample` method and a new `run_sampler` method is provided for efficiently (i.e. zero copying) sampler processing. A double buffer is used for continuously sampling, which wlll be swapped once sampling has taken place.
A sample frequency is provided and will set the internal timer of the SAADC when there is just the one channel being sampled. Otherwise, PPI will be used to hook up the TIMER peripheral to drive the sampling task.
One-shot mode now permits the sampling of differential pins, and the sampling of multiple pins simultaneously.
A new ChannelConfig structure has been introduced so that multiple channels can be configured individually. Further, the `sample` method now accepts a buffer into which samples are written.
Along the way, I've reset some default configuration to align with Nordic's settings in their nrfx saadc driver. Specifically, the channel gain defaults to 6 (from 4) and the time defaults to 10us (from 20us).
This crate contains async radio drivers for various lora drivers that
work with embassy timers. The code is imported from Drogue Device (
https://github.com/drogue-iot/drogue-device)
The radio drivers integrate with the async LoRaWAN MAC layer in the
lorawan-device crate.
Also added is an example for the STM32WL55 and for STM32L0 (requires
the LoRa Discovery board) for LoRaWAN. Future work is to make the
underlying radio drivers using fully async SPI when communicating
with the peripheral.
* Adds an executor for WASM runtimes based on wasm_bindgen.
* Add time driver based on JS time handling.
* Add example that can run in browser locally.
* Update to critical-section version that supports 'std' flag
Based on the HAL from stm32wl, the peripheral driver has been
modified to fit into embassy, using the embassy APIs, providing
operation of the radio peripheral.
The initial version does not offer any async APIs, but the example
shows how the radio IRQ can be used to perform async TX of the radio.
