High speed screen updates

[m-mcgowan]

Currently the screen updates are slow. This is for 2 reasons:

• each pixel set carries overhead
• the clock rate is lower than it could be due to the touch screen

This issue will address the first problem - reducing per-pixel overhead.

The most frequent method called is D4DLCD_Send_PixelColor_ili9341 to add one more pixel within the defined window. It results in 2 calls to D4DLCDHW_SendDataWord, which itself asserts/deasserts the Data Control line and then performs an SPI transfer, which asserts/deassers the Chip Select line, then calls SPI.transfer(). With many pixels sent back to back, that is considerable overhead that is unnecessary.

One way to speed this up is to buffer consecutive SendDataWord requests to a memory buffer, and then write this buffer as one SPI transaction. The buffer is written out when

• when full
• when a SendCommandWord request is received
• when a D4DLCD_FlushBuffer_Spi_Spark_8b is called, indicating the current object rendering is complete.

By using DMA and 2 memory buffers, we can transfer the data to the display asynchronously from one buffer while the other buffer is being filled with new data.

[elcojacobs]

This has been implemented in PR #62