You are reading a single comment by @Robin and its replies. Click here to read the full conversation.
  • 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:

    CSB can be “H”between parameter/ command. And SCL, SDA, D/C are invalid
    during CSB=”H”

    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:

    function wData(data) {
     digitalWrite(dcPin, 1);
     _spi.write(data);
    }
     digitalWrite(csPin, 0);
    for (let i=0;i<bufferSize;i++) wData(buffer[i]);
     digitalWrite(csPin, 1);
    

    Now this does not work anymore, because CS only changes once right before all the data writing.

    Changed it back to:

    function wData(data) {
     digitalWrite(dcPin, 1);
     digitalWrite(csPin, 0);
     _spi.write(data);
     digitalWrite(csPin, 1);
    } 
    for (let i=0;i<bufferSize;i++) wData(buffer[i]); 
    

    immediately starts working.

    I assume that

    _spi.write(data,csPin);
    

    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...?

About

Avatar for Robin @Robin started