| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
exposing pac items kind of undermines the unstable-pac feature. directly
exposing register structure is also pretty inconvenient since the clock
switching code takes care of the src/aux difference in behavior, so a
user needn't really be forced to write down decomposed register values.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
1458: rp: remove take!, add bind_interrupts! r=Dirbaio a=pennae
both of the uart interrupts now check a flag that only the dma rx path ever sets (and now unsets again on drop) to return early if it's not as they expect. this is ... not our preferred solution, but if bind_interrupts *must* allow mutiple handlers to be specified then this is the only way we can think of that doesn't break uarts.
Co-authored-by: pennae <[email protected]>
|
| | | |
|
| |/ |
|
| |
|
|
|
|
| |
It was intended to allow changing baudrate on shared spi/i2c. There's no
advantage in using it for PWM or PIO, and makes it less usable because you have to
have `embassy-embedded-hal` as a dep to use it.
|
| |\ |
|
| | | |
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1435: Added example for multi priority executors rp2040 r=Dirbaio a=fakusb
I added an example for multiple priorities of tasks on rp2040 by adjusting [examples/nrf52840/src/bin/multiprio.rs](https://github.com/embassy-rs/embassy/blob/master/examples/nrf52840/src/bin/multiprio.rs) .
This needs https://github.com/embassy-rs/rp-pac/pull/2 , and this commit also adds the 6 new interrupt handlers for software interrupts to embassy-rs.
We might need to change the git path for rp-pac in [embassy-rp/Cargo.toml](https://github.com/embassy-rs/embassy/compare/master...fakusb:rp2040-multiprio-executor?expand=1#diff-47463ea358745927ecdb686f52feab816fde5d402a9628a136c116f34a802ab0)
Closes #1413
Co-authored-by: Fabian Kunze <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| |
| |
| | |
execution wraps around after the end of instruction memory and wrapping
works with this, so we may as well allow program loading across this
boundary. could be useful for reusing chunks of instruction memory.
|
| | |
| |
| |
| |
| |
| | |
the many individual sets aren't very efficient, and almost no checks
were done to ensure that the configuration written to the hardware was
actually valid. this adresses both of these.
|
| | |
| |
| |
| |
| | |
these are needed a lot during state machine setup, it makes sense to
provide convenience functions for them.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
programs contain information we could pull from them directly and use to
validate other configuration of the state machine instead of asking the
user to pull them out and hand them to us bit by bit. unfortunately
programs do not specify how many in or out bits they use, so we can only
handle side-set and wrapping jumps like this. it's still something though.
|
| |/
|
|
|
|
| |
it's only any good for PioPin because there it follows a pattern of gpio
pin alternate functions being named like that, everything else can just
as well be referred to as `pio::Thing`
|
| |
|
|
|
|
|
| |
this *finally* allows sound implementions of bidirectional transfers
without blocking. the futures previously allowed only a single direction
to be active at any given time, and the dma transfers didn't take a
mutable reference and were thus unsound.
|
| |
|
|
|
|
|
|
|
| |
we can only have one active waiter for any given irq at any given time.
allowing waits for irqs on state machines bypasses this limitation and
causes lost events for all but the latest waiter for a given irq.
splitting this out also allows us to signal from state machines to other
parts of the application without monopolizing state machine access for
the irq wait, as would be necessary to make irq waiting sound.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
| |
next step: get rid of the insance trait entirely
|
| |
|
|
|
| |
pio can only access pins in bank 0, so it doesn't make sense to even
allow wrapping of other banks' pins.
|
| |
|
|
| |
these are just overly convoluted ways of writing down numbers.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
add an hd44780 example for pio. hd44780 with busy polling is a pretty
complicated protocol if the busy polling is to be done by the
peripheral, and this example exercises many pio features that we don't
have good examples for yet.
|
| |\
| |
| |
| |
| |
| |
| |
| | |
1414: rp: report errors from buffered and dma uart receives r=Dirbaio a=pennae
neither of these reported errors so far, which is not ideal. add error reporting to both of them that matches the blocking error reporting as closely as is feasible, even allowing partial receives from buffered uarts before errors are reported where they would have been by the blocking code. dma transfers don't do this, if an errors applies to any byte in a transfer the entire transfer is nuked (though we probably could report how many bytes have been transferred).
Co-authored-by: pennae <[email protected]>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
all handlers.
- Allows classes to handle vendor requests.
- Allows classes to use a single handler for multiple interfaces.
- Allows classes to access the other events (previously only `reset` was available).
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1142: More rp2040 BufferedUart fixes r=Dirbaio a=timokroeger
* Refactor init code
* Make it possible to drop RX without breaking TX (or vice versa)
* Correctly handle RX buffer full scenario
Co-authored-by: Timo Kröger <[email protected]>
|
| | |
| |
| |
| | |
Only unregister the interrupt handler when both parts are inactive
|
| |/ |
|
| | |
|
| | |
|
