embassy-rp: enable access to low-level PIO registers and values

[ericseppanen]

Existing code doesn't really support using PIO with complex DMA configurations (e.g. chaining dma channels to automatically loop buffers).

I found that there were a few things I wanted from embassy-rp to make these designs easier:

1. Access to the DREQ values for PIO FIFOs, to set up DMA pacing
2. Access to the FIFO hardware address, to load into the DMA read/write address register
3. Access to the PIO registers for debugging

I have been dropping down to rp-pac to do these things, but that fits poorly with the rest of my (embassy) code, and breaks down when using generic parameters for the pio and sm instances.

Feedback welcome! Feel free to bikeshed names, docs, etc.

[ericseppanen]

Would it be helpful to create an example that demonstrates the need for these? Something that needs to do DMA chaining, perhaps? See also #2842, #4190.

[CBJamo]

Ideally, the high level interface (of both DMA and PIO) would be expanded to cover your usecase.

The pac version is not bound to the semver of embassy-rp, so I think we cannot put registers in the public interface of embassy-rp.

[ericseppanen]

Ideally, the high level interface (of both DMA and PIO) would be expanded to cover your usecase.

Thanks for the feedback!

PIO+DMA can be combined in so many ways, that unless we have a bunch of applications to look at, it seems pretty hard to guess at an interface that supports a wide variety of use cases.

And since any high-level interface has to meet semver requirements, it can't evolve very quickly if it needs to wait for a new breaking release every time a change needs to be made. So I imagine it would be easier (both for downstream projects and for embassy-rp semver-compatibility) to allow people to do what they want with the PIO registers and then look for common patterns in the projects that result. I'm open to being proved wrong! I'm just not sure how to gather more information from the current state of things.

The pac version is not bound to the semver of embassy-rp, so I think we cannot put registers in the public interface of embassy-rp.

That's good to know. I'm confused though by the existence of embassy_rp::dma::Channel::regs()... doesn't that do the same thing? (it returns rp_pac::dma::Channel.)

[CBJamo]

All true, I think the best we can do is expand it as new uses come up. Since we're not 1.0 yet, I wouldn't worry too much about making breaking changes, so long as the new API's capabilities are a superset of the old one.

That's good to know. I'm confused though by the existence of embassy_rp::dma::Channel::regs()... doesn't that do the same thing? (it returns rp_pac::dma::Channel.)

Good catch, I think this might just be a mistake.

A middle ground has just occurred to me. The pac is re-exported with the unstable-pac feature. The fns you've added that expose the pac types could just be gated behind that feature. This makes it clear to users that the ground could shift below them.

[ericseppanen]

I'm confused though by the existence of embassy_rp::dma::Channel::regs()...

Good catch, I think this might just be a mistake.

I think this PR is dependent on the answer to that question.

If embassy-rp is going to allow dropping down to a lower level by calling e.g. Channel::regs() then it seems correct to allow the same for Pio (and in fact 2/3 of what's exposed in this PR are the pieces needed to connect to rp-pac DMA code).

If embassy will not allow this, and Channel::regs() will be removed, then this PR can be closed.

If dropping down to rp-pac will not be allowed, then I think embassy-rp will need some new DMA capabilities to replace the power that was just taken away. The DMA hardware is pretty expressive, so it would be a big task to express all of its capabilities in a safe high-level interface. I'm also not sure if the end result would be any easier to use than rp-pac registers. If this is the way you want to go I could try to get things moving by writing up a description of the problem with some examples.

[ericseppanen]

A middle ground has just occurred to me. The pac is re-exported with the unstable-pac feature. The fns you've added that expose the pac types could just be gated behind that feature. This makes it clear to users that the ground could shift below them.

That would be fine with me.