SPI.transfer(txbuf, rxbuf, count, block=false) provides an asynchronous write. Could then use the existing SPI.waitForTransfer() immediately before starting a new transfer or other transaction — this will only block if the current transfer is still in progress. If you need non-blocking, rather than a nested callback (which is probably just going to set a variable that you poll — and make sure it’s volatile), could be easier to add a “getter function” that returns the state of the SPI.dma_busy member (which will likely compile down to a direct access)…or, quick and dirty…could move that member to the “public” section…I know it’s bad form but is anyone really looking?

My goal was to set a FreeRTOS Semaphore on completion. Polling the volatile flag could work, but its not very elegant. Perhaps I would be better off just forking for my specific use case.

Would that be OK? It’s a pretty esoteric case and the first time it’s come up. I’d look at a PR if it’s something pretty minimal change though.

Hello Everyone,

I actually implemented this exact feature for the same reason @Timvrakas mentioned. The current implementation is technically only asynchronous for the transfer, and poling for completion sub optimal, especially if you are going to the trouble of doing a dma to save processor time to begin with. There is alot of performance that can be gained calling a function callback on dma completion as iv seen on my project with an oscilloscope.

I will post this pr soon, and it also fixes #230 as well.

Ok pull request posted :-)

Sorry, found this issue again during a github sweep. I think the transfer bugs (along with large DMA transfers) were both addressed in the 1.6.2 release a while back. If there’s a PR with just the callback additions, I could merge that.

I am looking at the code again and a lot has changed in the last year, im looking at what would need to be changed. I had made some architecture choices to deal with #230 and assumed that dma read only were not possible at that time.

I posted a follow up question for you in #230