-
Notifications
You must be signed in to change notification settings - Fork 132
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
Consider supporting extended DMA transfers #11
Comments
Hey @hannobraun, do you think a solution like #40 would work? My idea would be roughly as follows:
|
@jamesmunns |
I used exactly that feature of the nRF52832 in C already and it's really not that much sorcery. I think this should be easily doable but would require some nicer higher level interface to the PPI bus. |
Which would be a nice thing to have in itself! |
This issue was first opened in the old nrf52-hal repository. Original discussion: jamesmunns/nrf52-hal#14
The nRF52832's DMA channels are limited to buffers with a maximum length of 255 bytes. This is very limiting. For example, in the DW1000 driver, I need to support registers that are much longer than that (although there are ways to read/write subsets).
There is a way to use multiple consecutive buffers to circumvent this limitation. The product specification alludes to this (see section 10.1), but doesn't really explain how this works. I found the following discussions that provide a clearer picture:
Since this technique requires additional system resources (PPI, TIMER) and applies to all DMA channels, I think it's probably best to provide this as a separate layer that builds on top of DMA users like SPIM.
The text was updated successfully, but these errors were encountered: