As a workaround I allowed the DMA to overwrite my output buffer with the incoming "data":
SPI.transfer( ((uint8_t ) &EVE_dma_buffer[0])+1, ((uint8_t ) &EVE_dma_buffer[0]), (((EVE_dma_buffer_index)*4)-1), false );
But only after I ran into the issue that this write-only transfers are appear to be working while killing following SPI.transfer(0x00) calls.
I suggest to not allow write-only transfers untill these actually do work to not let others fall into this trap.
This could be done by not allowing a NULL pointer for rxbuff.
I fixed my issue with a workaround but after that I went back to use ZeroDMA instead.
As I wrote here: https://github.com/adafruit/Adafruit_ZeroDMA/issues/24 write-only transfers with https://github.com/adafruit/ArduinoCore-samd/blob/master/libraries/SPI/SPI.cpp are currently not working.
The issue is that the receiver needs to be disabled in the SERCOM units but SPI.cpp is not directly writing to the SERCOM unit, it is using https://github.com/adafruit/ArduinoCore-samd/blob/master/cores/arduino/SERCOM.cpp and SERCOM.cpp currently has no methods implemented to disable and re-enable the transceiver.
As a workaround I allowed the DMA to overwrite my output buffer with the incoming "data": SPI.transfer( ((uint8_t ) &EVE_dma_buffer[0])+1, ((uint8_t ) &EVE_dma_buffer[0]), (((EVE_dma_buffer_index)*4)-1), false );
But only after I ran into the issue that this write-only transfers are appear to be working while killing following SPI.transfer(0x00) calls.
I suggest to not allow write-only transfers untill these actually do work to not let others fall into this trap. This could be done by not allowing a NULL pointer for rxbuff.
I fixed my issue with a workaround but after that I went back to use ZeroDMA instead.