I have succesfully connected my LCD with I2C and I could run all Arduino samples.

But now I jumpered the LCD for SPI and some features don't work correctly.

1. I can't draw 262k images ( eyes )

2. the flashing / negative text doesn't work (setMode(' ~' ) )

Is it, because the ESP8266 SPI setting is too fast?

 Most possible: Yes, the receiving buffer in display could be overflowed if data speed too fast.

How can I reduce SPI speed?

I don't use <SPI.h>, but only <DigoleSerial.h> and I don't see a way to reduce speed.

<SPI.h> has the option to set halfspeed, quarterspeed and so on, but not when i call <DigoleSerial.h>.

I studied DigoleSerial.h and found these three lines in the SPI version of void read1()

        digitalWrite(_SSpin, LOW); //tell display module I will read data
        digitalWrite(_SSpin, LOW); //delay about 5us to wait module prepare data
        digitalWrite(_SSpin, LOW); 

Maybe this doesn't work on faster MCUs like the ESP8266 ( 80MHz )?

After a bit more testing, I got the touchscreen_freehands_demo working over SPI and also the font_commandset_in_flash.

But the combination of flash and touchscreen only works over i2c ( checkbox and radiobuttons_demo )

You mentioned a pulldown resistor for the SI pin to make flash and touchscreen work in SPI mode,but there already is a 4.7k resistor on the SDO pin of the LCD.

Do we have to add a pulldown resistor to the data pin?

I am testing in Python and therefore I cannot see the i2c source code. But by trial and error, I found there is a relation with the i2c clock frequency and a short latency between sending the data size and the data them selves.

Default in my environment is i2c frequency=400000. Most of the communication runs well at this speed, including the also sensitive sending of colour images. So far, the best i can do with downloadUserFont and downloadStartScreen is 200000 plus 200ms delay before starting streaming the data.

Also, The 64 bytes chunk latency must be set to 40ms as documented, whereas in the other functions sofar 5ms still works well.

Hi..As you can see it uses the SPI hardware very different than your display. The "easy" way around this is to do as Nick said and use software SPI for one of them.
This shows one of the problems with the Arduino SPI implementation and how this ripples into libraries and basically makes it a single SPI device software interface. The current implementation is also very difficult to use with interrupts and threads (i.e. concurrent programming).

us pcb assembly