Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Post here first, or if you can't find a relevant section!
stevestrong
Posts: 1019
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby stevestrong » Thu Feb 23, 2017 8:36 am

In my code I initialized the DMA once (dmaSendInit()), then I just updated the number of data to transfer and the pointer in dmaSendBuffer() and enabled the DMA, so that the overhead could be kept minimal.
I will post my version here in the evening.

racemaniac
Posts: 364
Joined: Sat Nov 07, 2015 9:09 am

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby racemaniac » Thu Feb 23, 2017 8:51 am

stevestrong wrote:In my code I initialized the DMA once (dmaSendInit()), then I just updated the number of data to transfer and the pointer in dmaSendBuffer() and enabled the DMA, so that the overhead could be kept minimal.
I will post my version here in the evening.

yup, same here when doing dma :).

victor_pv
Posts: 1249
Joined: Mon Apr 27, 2015 12:12 pm

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby victor_pv » Thu Feb 23, 2017 3:47 pm

racemaniac wrote:
victor_pv wrote:
racemaniac wrote:indeed :). It would still be nice to be able to configure that you won't reuse the dma channel for something else and get the cheaper dma setup (likely the most often usecase since so far dma is hardly used anyway ^^)


If I understand right, you are suggesting to add functions that could repeat a dma transfer already set before?
Something like:

Code: Select all

SPI.dmaSetTX (uint16 *buffer, uint16 length, bool minc);
SPI.dmaRepeatTX();
... refilling buffer, etc ...
SPI.dmaRepeatTX();


That could make sense. I have to check the dma info, but I believe we only need to reset the length again before repeating a dma transfer, everything else stays, should remove some overhead.

yup, something like that. we can see how much can be reconfigured (also changing the target address could also be an option, is just 1 write to a register). But going for the full dma setup everytime seems a bit overkill most of the time :)


It is overkill you are using the port for a single device so you mostly just reuse the buffers, speeds and what not, but if you have let's say SDCard and TFT in the same port, the buffer, lengths of transmission, whether you use circular mode or not... will all change. They are mean to provide an easy way to use DMA without having to change the driver's code much for general usage, without being too specific or difficult to use.

As you see most people don't even try to use DMA in any device.

racemaniac
Posts: 364
Joined: Sat Nov 07, 2015 9:09 am

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby racemaniac » Thu Feb 23, 2017 3:55 pm

ugh, that eternal trade off between performance and usability of a framework ^^'
there indeed is no silver bullet or "best" solution >_<. i'd still like the cheap setup functions for when using DMA directly, but for usage in frameworks, the full setup is indeed the safer choice.

stevestrong
Posts: 1019
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby stevestrong » Thu Feb 23, 2017 6:09 pm

I think we could reserve the DMA usage of channels 2 to 5 for SPI1 and 2 (both Rx and Tx), user configurable. The other channels would be then always free for other purposes.
I am attaching my local version of SPI.cpp, where I started to implement a dual-buffered DMA transfer: while sending one buffer, the other buffer gets filled. When the first is sent, in the ISR is checked whether the other buffer contains data to send or not. If yes, the DMA will be setup automatically again. So far the plan, but the ISR part is not yet coded.
The interesting functions start from line 479, conditioned by the SPI_USE_DMA define.
Hopefully you can get some ideas from it.
Attachments
SPI.cpp
(25.65 KiB) Downloaded 10 times

Ollie
Posts: 151
Joined: Thu Feb 25, 2016 7:27 pm

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby Ollie » Fri Feb 24, 2017 4:15 pm

An additional reference can be found at http://www.emblocks.org/wiki/tutorials:f401_f429_disco:spi. I have included the Logic Analyzer screenshots to show how 3 SPI devices are communicating at the same time using DMA for the bulk processing.

This is based on the principle that the SPI transfer requests are non-blocking. That means that the requests are put into a queue. When taking a request from the queue the following actions are done
- the device address is sent using polling
- the register number is sent using polling
- one or two DMAs are setup depending if it is read, write, or simultaneous read and write
- interrupt is set for DMA completion
- once the interrupt is received, the "callback" is executed and the next transfer is started

This code demonstrates how the speed and other SPI settings can be changed for different devices and how the SPI configuration registers are modified only when required.

This code demonstrates how the LCD driver command/data line is driven synchronized with the SPI transfers.

Cheers, Ollie

stevestrong
Posts: 1019
Joined: Mon Oct 19, 2015 12:06 am
Location: Munich, Germany

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby stevestrong » Fri Feb 24, 2017 4:48 pm

Ollie wrote:This code demonstrates how the LCD driver command/data line is driven synchronized with the SPI transfers.
Cheers, Ollie

My code does exactly the same :)

Btw, if the software does polling, I am not sure that is really "non-blocking": what happens if the polling is unsuccessful?
And of course, non-blocking can only be achieved using DMA.

User avatar
mrburnette
Posts: 1779
Joined: Mon Apr 27, 2015 12:50 pm
Location: Greater Atlanta
Contact:

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby mrburnette » Sat Feb 25, 2017 3:56 pm

.... thinking out loud.... no response expected ....

Anyone looked into what Paul Stoffregen is doing around Teensy 3.1/3.2 ?

User avatar
RogerClark
Posts: 5615
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby RogerClark » Sat Feb 25, 2017 8:24 pm

mrburnette wrote:.... thinking out loud.... no response expected ....

Anyone looked into what Paul Stoffregen is doing around Teensy 3.1/3.2 ?


Good point Ray.

Paul usually thinks these things through very carefully, so its worth looking at what he had implemented for the Teensy.
The Teensy hardware does however differ from the STM32 and I know it has some more advanced DMA abilities than is available on the F103

victor_pv
Posts: 1249
Joined: Mon Apr 27, 2015 12:12 pm

Re: Planning to add callback to the SPI DMA functions (dmaSend, dmaTransfer...)

Postby victor_pv » Sat Feb 25, 2017 10:51 pm

From what I have found, they have not integrated any DMA functions in the normal SPI library.
There is another library, DmaSpi, which is the one that has DMA capabilities:

https://github.com/crteensy/DmaSpi

That one works similar to what Steve was working on, it queues transfers with a series of properties (buffer pointer, size, and a pin object to control CS), then services those transfers in order.

Not sure if all that is worth the effort, as Steve tested, for small transfers doesn't improve performance due to all the overhead, and the libraries using it have to be heavily modified.


Return to “General discussion”

Who is online

Users browsing this forum: No registered users and 1 guest