KurtE - what would a test for SPI Asynch Xfer look like?
Many different ways. The test sketch I uploaded as part of the previous message, has calls to do Sync and Async calls to SPI.transfer. There are calls that do Write only, Read only (sends dummy char default 0), or full transfers.
The code internally is setup to do copy of up to 32767 bytes per transfer, if user specifies more, the ISR that triggers at the DMA will restart the DMA operation to continue it... Could have chained requests, but...
For Teensy 3.5/6 I had a version of Teensyview that had option to do asynch updates. At the time I had tests running where I had multiple displays being updated, one on each SPI buss... But only have one BUS and obviously can only do DMA to one of the devices at a time on the same SPI buss...
But I am setting up my hacked up Adafruit_SSD1306 library to allow the use of the Async update... Will then be a fun test to try updating one on the Hardware SPI buss and one on FLEX IO buss...
At one point, I had a version of my ili9341_t3n library (_t3ns), that had the frame buffer and instead of using all of the SPI FIFO queue stuff like the _t3 or _t3n does it used SPI calls...
However at the time I had it using a version of the transfer that Paul did not want in the library: 16 bit buffer transfer:
_spi->transfer16(_pfbtft, NULL, _width*_height); // blast it out.
or:
_spi->transfer16(_pfbtft, NULL, _width*_height, _event_responder); // blast it out.
So I have not touched this one in awhile. I could probably have hacked up the backing memory to reverse the color bytes so we could just use transfer...