Commit Graph

110 Commits

Author SHA1 Message Date
huntc
c9f29534d6 Stop PWM before assigning the new sequence
I had introduced a small bug in my last PR where I assigned the sequence before stopping the PWM. I now stop the PWM before doing that now.

Also, corrected a math comment.
2022-01-25 16:51:24 +11:00
huntc
48afef28a0 Strengthen the borrow
The start method is now safe. Because it has the potential of borrowing the sequence and mutating itself, the sequence must outlive the Pwm struct.
2022-01-24 17:22:35 +11:00
huntc
7598b8a40f Permit many sequences to be passed
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.
2022-01-23 16:29:52 +11:00
Dario Nieuwenhuis
7997687f3b nrf: impl embedded-hal 1.0 and embedded-hal-async traits. 2022-01-13 23:56:39 +01:00
Dario Nieuwenhuis
6eec3d8acc nrf/rng: expose all functionality as inherent methods. 2022-01-13 23:56:39 +01:00
Dario Nieuwenhuis
df00c83984 nrf/qspi: expose all functionality as inherent methods. 2022-01-13 23:56:39 +01:00
Dario Nieuwenhuis
3e503e7335 nrf/uarte: expose all functionality as inherent methods. 2022-01-13 23:56:39 +01:00
Dario Nieuwenhuis
c432d036c7 nrf/gpiote: expose all functionality as inherent methods. 2022-01-13 23:56:39 +01:00
Dario Nieuwenhuis
ecb4f8fb00 nrf/twim: expose all functionality as inherent methods. 2022-01-13 23:56:39 +01:00
Dario Nieuwenhuis
a287fef687 nrf/spim: expose all functionality as inherent methods. 2022-01-13 23:56:39 +01:00
huntc
d5d8897c84 Remove unsafe from new on RND
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.
2022-01-06 09:59:28 +11:00
bors[bot]
f744b74e90
Merge #539
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>
2022-01-04 07:41:54 +00:00
Dario Nieuwenhuis
22bc1e4ae1 nrf/gpio: add infallible inherent methods, remove some duplication.
This implements Input and Output using FlexPin, to avoid some code duplication.
2021-12-20 00:55:18 +01:00
Jacob Rosenthal
e7d2c52680 example cleanup 2021-12-16 15:20:56 -07:00
Jacob Rosenthal
1d51f91368 usb_uart_io example equivilent to usb_uart 2021-12-16 14:59:35 -07:00
Jacob Rosenthal
1f2bbe3e4a simplify usb_uart example 2021-12-16 14:59:08 -07:00
bors[bot]
5df16c6793
Merge #544
544: Introduces split on the nRF Uarte r=Dirbaio a=huntc

A new `split` method is introduced such that the Uarte tx and rx can be used from separate tasks. An MPSC is used in an example to illustrate how data may be passed between these tasks.

The approach taken within the `Uarte` struct is to split into tx and rx fields on calling `Uarte::new`. These fields are returned given a call to `Uarte::split`, but otherwise, if that call isn't made, then the API remains as it was before.

Here's a snippet from a new example introduced:

```rust
#[embassy::main]
async fn main(spawner: Spawner, p: Peripherals) {
    // ...

    let uart = uarte::Uarte::new(p.UARTE0, irq, p.P0_08, p.P0_06, NoPin, NoPin, config);
    let (mut tx, rx) = uart.split();

    // ...

    // Spawn a task responsible purely for reading

    unwrap!(spawner.spawn(reader(rx, s)));

    // ...

    // Continue reading in this main task and write
    // back out the buffer we receive from the read
    // task.
    loop {
        if let Some(buf) = r.recv().await {
            info!("writing...");
            unwrap!(tx.write(&buf).await);
        }
    }
}

#[embassy::task]
async fn reader(mut rx: UarteRx<'static, UARTE0>, s: Sender<'static, Noop, [u8; 8], 1>) {
    let mut buf = [0; 8];
    loop {
        info!("reading...");
        unwrap!(rx.read(&mut buf).await);
        unwrap!(s.send(buf).await);
    }
}
```


Co-authored-by: huntc <huntchr@gmail.com>
2021-12-16 07:44:40 +00:00
Jacob Rosenthal
5d19f87acb cleanup example 2021-12-15 12:30:48 -07:00
Jacob Rosenthal
61f12324ff enable USB peripheral for relevant chips 2021-12-15 10:23:19 -07:00
Jacob Rosenthal
79502330de rename to UsbBus 2021-12-15 09:59:56 -07:00
huntc
1374ad2ab6 Introduces split on the nRF Uarte
A new `split` method is introduced such that the Uarte tx and rx can be used from separate tasks. An MPSC is used to illustrate how data may be passed between these tasks.
2021-12-15 18:31:52 +11:00
Jacob Rosenthal
5f0fefbd25 dont rely on nrf-usdb 2021-12-14 16:51:34 -07:00
Jacob Rosenthal
3debe604fb sorta works, too many interupts? 2021-12-14 16:48:48 -07:00
Jacob Rosenthal
07cbd41131 dont expose embedded_hal_common::usb 2021-12-14 15:47:54 -07:00
Jacob Rosenthal
f31140a70b revert 2021-12-14 13:51:50 -07:00
bors[bot]
1a7b9e3279
Merge #542
542: nrf/gpiote: remove PortInput, move impls to Input/FlexPin. r=Dirbaio a=Dirbaio

`PortInput` is just a dumb wrapper around `Input`, it has no reason whatsoever to exist. This PR moves the `wait_for_x` functionality to `Input` directly.

It also adds it to `FlexPin` for completeness and consistency with `Input`.

(The reason `PortInput` exists is a while ago `GPIOTE` was an owned singleton that you had to initialize, so `PortInput::new()` would require it to enforce it's been initialized. This doesn't apply anymore now that GPIOTE is "global")

Co-authored-by: Dario Nieuwenhuis <dirbaio@dirbaio.net>
2021-12-14 14:09:59 +00:00
Dario Nieuwenhuis
153b1bbdbf nrf/gpiote: remove PortInput, move impls to Input. 2021-12-14 13:23:40 +01:00
Jacob Rosenthal
535d30335a make send, consolidate usb types 2021-12-13 18:13:42 -07:00
Jacob Rosenthal
83a1237ea3 stub out the embassy registers for usbd 2021-12-13 18:04:54 -07:00
Jacob Rosenthal
e5dc63e8e9 usb feature gate 2021-12-12 21:39:59 -07:00
Jacob Rosenthal
f430c0e8c2 nrf-usbd 2021-12-12 19:20:02 -07:00
huntc
dc3469b297 Documents the nRF BufferedUarte problem
Please see https://github.com/embassy-rs/embassy/issues/536 for the rationale.
2021-12-12 17:52:17 +11:00
Ulf Lilleengen
9b01eed195 Revert blinky changes for now 2021-12-10 12:32:20 +01:00
Ulf Lilleengen
e93f2679b1 More content 2021-12-10 12:27:44 +01:00
huntc
7256ff3e71 Provides AsyncWrite with flush
As per Tokio and others, this commit provides a `poll_flush` method on `AsyncWrite` so that a best-effort attempt at wakening once all bytes are flushed can be made.
2021-12-10 12:16:08 +11:00
huntc
469852c667 Removed unsafe from uarte
The constructors themselves are not strictly unsafe. Interactions with DMA can be generally unsafe if a future is dropped, but that's a separate issue. It is important that we use the `unsafe` keyword diligently as it can lead to confusion otherwise.
2021-12-01 09:14:24 +11:00
bors[bot]
c7d9729028
Merge #486
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>
2021-11-26 23:08:24 +00:00
Matous Hybl
0ca6060bfd Fix interrupt_take macro by specifying path to panic macro. 2021-11-23 11:00:37 +01:00
Dario Nieuwenhuis
9b17b3d721 Remove unused deps 2021-11-15 20:13:22 +01:00
Bob McWhirter
23fdca9e52 Remove extraneous defmt-trace feature. 2021-11-15 11:33:44 -05:00
Bob McWhirter
a770fc77c9 Adjust all examples to defmt 0.3. 2021-11-15 11:19:19 -05:00
Jacob Rosenthal
2bcacd4f16 nrf: sequencepwm add events 2021-11-13 16:24:41 -07:00
Jacob Rosenthal
aca7b86c7e pwm_sequence show implicit and explicit stop functionality 2021-11-11 23:47:35 -07:00
Jacob Rosenthal
b4cb24c735 pwm_servo example comment for clarity 2021-11-11 23:32:34 -07:00
Jacob Rosenthal
67baec472d nrf: dump the pwm_sequence example for clarity
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
2021-11-11 23:31:10 -07:00
Jacob Rosenthal
937f49dead nrf: sequencepwm rename top to max_duty for consistancy 2021-11-11 22:47:57 -07:00
Jacob Rosenthal
ea1c62ff61 fix 2021-11-11 20:12:50 -07:00
Jacob Rosenthal
639034cee4 fix 2021-11-11 19:58:45 -07:00
Jacob Rosenthal
ec66fcd01a pwm_sequence consume buffer 2021-11-11 19:14:29 -07:00
bors[bot]
4112759a8f
Merge #455
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>
2021-11-11 16:26:36 +00:00