I had a similar requirement as @BriscoeTech (see PR #234) for user-specified callbacks to enable full DMA flow control for SPI transfers.
Because of the way the DMA control currently works (depending on mode read, read/write, or write, only one DMA channel has an active callback), I keep duplicate pointers to the user's callback in a list matching spiPtr. This way, the existing dmaCallback can be extended without changing the current DMA descriptor table allocations (long transfers should be unaffected).
Resolves #225.
Related observation: without interrupts configured, begin/end Transfer are not really required, except config is private. Adding a public interface for config would clean that up, but I didn't put it in this PR.
Tested on the Metro Express M0 with a Mikroe EasyADC, software _SS control.
I had a similar requirement as @BriscoeTech (see PR #234) for user-specified callbacks to enable full DMA flow control for SPI transfers.
Because of the way the DMA control currently works (depending on mode read, read/write, or write, only one DMA channel has an active callback), I keep duplicate pointers to the user's callback in a list matching spiPtr. This way, the existing dmaCallback can be extended without changing the current DMA descriptor table allocations (long transfers should be unaffected).
Resolves #225.
Related observation: without interrupts configured, begin/end Transfer are not really required, except config is private. Adding a public interface for config would clean that up, but I didn't put it in this PR.
Tested on the Metro Express M0 with a Mikroe EasyADC, software _SS control.