-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type erase DMA channels from peripheral drivers #2248
Comments
This is an idea I've been toying with for a while now and if you can make it work, that's awesome and enables quite a bit more, like giving the same treatment to peripheral instances. However, the benefits are a bit more nuanced than with GPIOs. The examples you cherry-picked are working because the DMA channel is the last type parameter, but it needs a bigger change for
We shouldn't need those I think. As long as the peripheral constructor makes sure to only take a suitable channel, we should be able to convert that to an AnyChannel, I hope. |
Terms and conditions apply:
This might be a bit more hairy than ideal :) |
Yeah we can put a pin on the PDMA side 😄
Yeah I was being cheeky there, I might leave the messier ones as an exercise to other motivated developers. |
Turns out the Rust insists that any generic params with defaults must be last in the list of params, or rather there must be no non-default params to the right of it. |
I think we can and should avoid PDMA specific stuff, and only have I.e pub fn with_dma<C, DmaMode>(
self,
mut channel: Channel<'d, C, DmaMode>,
) -> SpiDma<'d, crate::peripherals::SPI2, C, M, DmaMode>
where
C: DmaChannel,
C::P: SpiPeripheral + Spi2Peripheral,
DmaMode: Mode,
{
channel.tx.init_channel(); // no need to call this for both, RX and TX
SpiDma {
spi: self.spi,
channel: channel.into(), // convert the channel into `AnyDmaChannel` since we now know the channel can be used with this peripheral.
_mode: PhantomData,
}
} |
That's going to be tough, at least with the way I'm planning to implement erasure. We can discuss further when I make the erasure PR, as we'll have something more concrete to scrutinize. |
Sounds good, if you have a sketch on how you'd impl it we can discuss it before the PR. I'd like to avoid |
There's a write up in the PR description. (I already had a draft yesterday (don't tell Daniel) which is why I made the PR instead of discussing/sketching it out first) |
The goal of this issue is to (optionally) erase the dma channel type information from drivers.
i.e.
I8080<'d, DmaChannel0>
->I8080<'d>
Camera<'d, DmaChannel2>
->Camera<'d>
SpiDma<'d, ...., SpiDmaChannel>
->SpiDma<'d, ....>
Achieving this will require the following changes.
RegisterAccess
trait will have to be changed to take&self
/&mut self
rather than being static/global. This will allow it to hold some state, which will be the "channel number".ChannelRx<_>
andChannelTx<_>
, theRegisterAccess
trait will have to be split up into an RX half and TX half.self
being added to theRegisterAccess
trait, so it's easier if the interrupt methods go into a separate trait. So in total there's three traits, RX, TX, Interrupts.self
, on the GDMA side aAnyDmaChannel
can be implemented.AnySpiChannel
andAnyI2sChannel
can be implemented. (Just in case, if you're wondering whyAny
is useful on the PDMA side, go look at the base ESP32's TRM's DMA section)I've started with #2247 to make my life easier in RustRover.
The text was updated successfully, but these errors were encountered: