Commit Graph

10 Commits

Author SHA1 Message Date
pennae
486fe9e59d rp/pio: remove PioStateMachineInstance
move all methods into PioStateMachine instead. the huge trait wasn't
object-safe and thus didn't have any benefits whatsoever except for
making it *slightly* easier to write bounds for passing around state
machines. that would be much better solved with generics-less instances.
2023-05-03 11:25:58 +02:00
pennae
906d2b2db7 rp/pio: PioStateMachine{Instance, => ,Instance}
next step: get rid of the insance trait entirely
2023-05-03 11:25:58 +02:00
pennae
4ccb2bc95a rp/pio: add PioPin trait
pio can only access pins in bank 0, so it doesn't make sense to even
allow wrapping of other banks' pins.
2023-05-03 11:25:43 +02:00
pennae
7a36072a15 rp/pio: drop SmInstance{,Base}
these are just overly convoluted ways of writing down numbers.
2023-05-02 18:01:18 +02:00
pennae
a167c77d39 rp/pio: make PioCommon a struct
the PioCommon trait does not serve much of a purpose; there can be only
two implementations and they only differ in a few associated constants.
2023-05-02 18:01:18 +02:00
pennae
8839f3f62a rp/pio: PioInstance::split -> Pio::new
not requiring a PioInstance for splitting lets us split from a
PeripheralRef or borrowed PIO as well, mirroring every other peripheral
in embassy_rp. pio pins still have to be constructed from owned pin
instances for now.
2023-05-02 15:52:50 +02:00
pennae
3229b5e809 rp/pio: remove PioPeripheral
merge into PioInstance instead. PioPeripheral was mostly a wrapper
around PioInstance anyway, and the way the wrapping was done required
PioInstanceBase<N> types where PIO{N} could've been used instead.
2023-05-02 15:46:21 +02:00
pennae
f4ade6af8b rp/pio: write instr memory only from common
instruction memory is a shared resource. writing it only from PioCommon
clarifies this, and perhaps makes it more obvious that multiple state
machines can share the same instructions.

this also allows *freeing* of instruction memory to reprogram the
system, although this interface is not entirely safe yet. it's safe in
the sense rusts understands things, but state machines may misbehave if
their instruction memory is freed and rewritten while they are running.
fixing this is out of scope for now since it requires some larger
changes to how state machines are handled. the interface provided
currently is already unsafe in that it lets people execute instruction
memory that has never been written, so this isn't much of a drawback for now.
2023-05-01 12:58:57 +02:00
pennae
58e727d3b9 rp/pio: move non-sm-specific methods to PioCommon
pin and irq operations affect the entire pio block. with pins this is
not very problematic since pins themselves are resources, but irqs are
not treated like that and can thus interfere across state machines. the
ability to wait for an irq on a state machine is kept to make
synchronization with user code easier, and since we can't inspect loaded
programs at build time we wouldn't gain much from disallowing waits from
state machines anyway.
2023-05-01 12:58:57 +02:00
Caleb Jamison
12d6e37b3f Example using the PIO to drive WS2812 aka Neopixel RGB leds
This example also uses a pio program compiled at runtime, rather than one built at compile time. There's no reason to do that, but it's probably useful to have an example that does this as well.
2023-03-11 02:58:28 -05:00