'I guess that could speed up the data transfer loop...?'
Yes, by a small amount. But, . . . isn't the data bit rate set by the setup of SPI? (yes)
As the image in #16 is helpful here, has the use of an inexpensive logic analyzer been used?
I thought I had some images of SPI clocking at 100000 baud (without the need for inline' C') in action, but is actually the UART Tx-Rx - similar output post #3 there you'll get the idea though - one way of speeding development here
What about SPI.send() vs SPI.write() ?
SPI syntax for receive string clarification and sanity check please
So, I think I found the culprit. I (again) had a look at the display driver specs and on page 16 it shows the cycle graph(?) for the 4-wire SPI interface, see attached image.
Below the graph it says:
That and the rising flank of the CSB signal after the 8 databits on the right, leads me to believe that CS needs to be pulled down and up again for every byte written.
So I changed my write function like so:
Now this does not work anymore, because CS only changes once right before all the data writing.
Changed it back to:
immediately starts working.
I assume that
also pulls down csPin only once.
So now the questions would be: would it be feasible to create a native SPI write function that pulls the cs(nss) pin down for every byte written and does that make sense?
Would my case still benefit speedwise? Otherwise I would be stuck to my single bytes write algorithm and the speed bottleneck it causes.
EDIT: Just stumbled across Espruinos capability of inline C code. I guess that could speed up the data transfer loop...?