Idea: Faster LCD redraw with 16 MHz I2S (instead of 8 MHz SPI)

• I searched for similar feature request and found none was relevant.

Pitch us your idea!

Faster display redraw

Description

Hi there,

Short story:

It seems like it could be possible to use I2S peripheral as a "faster SPI" running at 16 MHz (double of SPI speed)

Long story:

I could be wrong, Iooking for some feedback.
I'm a low-level embedded developer and I like challenges like driving a lot of smart LEDs with not-so-fast processors.
Since NRF52832 has SPI divisor which can run at maximum 8 MHz speed, I tried to look around on other peripherals and see what could be use. PWM and other peripherals end at 8 MHz too, but I2S looked promising.

InfiniTime and ST7789 is using SPI MODE3, which means CLPH = 1 and CLKPOL = 1. It looks like this on logic analyzer

SPI 8 MHz SLPOUT 0x11 command

Sampling is on the rising edge.
Fortunatelly the I2S format is similar and data are changed when clock is low and data are present on the rising edge.

By using i2s example from NRF52 SDK \examples\peripheral\i2s I was able to generate same waveform with steady data on the clock rising edge.

here from the scope

Signal above is 4 MHz and my Saleae clone analyzer has 24 Msps and aliasing issues with 16 MHz signal. So I connected my scope to see 16 MHz signal. Don't be scared with signal integrity, it has no proper grounding. Also it was debugged on hardware which has also some capacity load on those specific pins on the PCB.

If I did not overlooked something this might be usable.

What needs to be done:

• Investigate whether the signal is usable at those speeds (NRF can have some limits, however they state that up to 16 MHz clock on I2S is supported). On the 8 MHz the data is stable on rising edge. On 10 and 16 MHz it does not look like the data is stable on rising edge. On 10 MHz the clock stays more time in the positive side, so it seems like I2S is doing some clock magic which could be show-stopper on 10 & 16 MHz. (More screens below in Update)
  
• Add pinmux switching to SPI driver which will choose SPI for SPI FLASH (needs MOSI + MISO) or I2S (only "MOSI") for LCD based on chip_select pin
• Check if data could be clocked properly from the first byte. NRF example I tested has some zero bytes in the begining, but I didn't have time to investigate that whether it is code or peripheral issue (image below)
  

Update:

Did again measurement with only scope connected to those signals and measured 8, 10 & 16 MHz signals.
It looks that with 10 & 16 MHz the clock is really out of phase and on the clock rising edge also data is changing.
8 MHz seems fine, data stable on rising clock

10 MHz and above seems to me that data is not stable on rising clock.. :(

If anyone is interested I can ZIP and share my edited i2s example project. Did some ugly changes and not sure what I changed exactly from the default code/SDK configuration.

Unfortunatelly I do not have time or development kit to continue, so here my journey ends. It would be great if this idea will be reviewed by other developers and tested by someone who can create basic working proof of concept.

Start by reviewing the SPI driver and the nRF52 SDK I2S peripheral example, then verify the 8, 10, and 16 MHz waveforms and first-byte behavior. Done means establishing whether I2S can reliably drive the ST7789 at the faster rate and producing a basic proof of concept with pinmux switching for the LCD and SPI flash.