Working code in this post, and an explanation how to modify sdFat to use it in the next post after that:
http://www.stm32duino.com/viewtopic.php ... =60#p30306
This is something Roger has suggested several times, and it seems to only make sense.
Currently the dma TX/RX functions we added to the SPI library block until the DMA transfer is completed or has timed out.
This change would add 2 functions to the SPI library, similar to the Arduino official I2S library:
Code: Select all
If the user code calls those functions and sets a handler function to be called on completion, the SPI dma functions will not block after setting up the transfer, and instead will set that handler function as the call back to the core, and return immediately.
The user code will be responsible for not initiation another transfer until confirming the previous one is completed.
If the user code doesn't set a handler, or sets the handler back to NULL (default value), then the SPI dma functions will block as currently until the DMA is completed.
The core currently has the functionality to manage the callback, but is not used since we decided to block.
One thing to decide is whether the SPI will implement it's own ISR to disable the spi DMA requests on the corresponding channel when the transfer is completed, or leave that to the user code. If the spi dma requests are not disabled after a transfer, then if the program wants to use the same dma channel for another peripheral, it can find the spi peripheral causing extra dma requests, so would be undesirable.
The main benefit would be to increase parallelism. If dmaSend returns immediately the CPU can go to work on something else.
This will require a bit more RAM and flash usage.
Anyone has ideas, suggestions, opinions?