Driving high-resolution displays over QSPI

RE: Driving high-resolution displays over QSPI

Håkon Alseth — Tue, 07 Feb 2023 14:03:37 GMT

Hi,

[quote user="charliebruce"]Are there any undocumented/test registers that would allow us to change opcodes and/or disable the pagination behaviour?[/quote]

No, unfortunately not.

Kind regards,

Håkon

RE: Driving high-resolution displays over QSPI

Charlie — Tue, 07 Feb 2023 13:50:30 GMT

On one of our candidate displays, the display driver has no RAM of its own, requiring a full refresh every frame. Regardless of display controller, we will also have rotating elements taking up most of the screen, also requiring a full refresh. So unfortunately updating only a small area of the display isn't practical.

Are there any undocumented/test registers that would allow us to change opcodes and/or disable the pagination behaviour? If available, this would be a preferable solution, rather than messing around with external muxes, PPI/PWM/GPIOTE, or trying to bit-bang the right output.

RE: Driving high-resolution displays over QSPI

Håkon Alseth — Tue, 07 Feb 2023 13:33:19 GMT

Hi,

[quote user="charliebruce"]Single SPI would put significant limits on our maximum frame rate (360x360x16bpp at 32MHz would limit us to 15 FPS, larger resolutions would run even slower), so QSPI is highly preferable.[/quote]

What has been done in previous scenarios where a display are being used is to store display data on an external flash using QSPI, and use SPIM for the display communication.

Is writing the full frame required by your display? Or can you update only the fields that require updating? You normally only change what needs to be changed.

[quote user="charliebruce"]One option that could theoretically work without going outside of spec might be to use the PWM peripheral to generate the correct sequence (tightly in step with the QSPI), then mux the pin back to the QSPI pin once the opcode and address has been sent (either internal or external mux) - that's the level of complexity that we'd be OK with.[/quote]

As mentioned, using the QSPI for other operations than NOR-flash compatible command set is not trivial. I do not know if this will work for your use-case, but you are free to evaluate.

Kind regards,

Håkon

RE: Driving high-resolution displays over QSPI

Charlie — Mon, 06 Feb 2023 12:03:30 GMT

Hi Håkon,

Single SPI would put significant limits on our maximum frame rate (360x360x16bpp at 32MHz would limit us to 15 FPS, larger resolutions would run even slower), so QSPI is highly preferable.

We're potentially OK with complex workarounds (eg test registers/undocumented behaviour), provided that the solution is likely to persist through minor chip revisions.

One option that could theoretically work without going outside of spec might be to use the PWM peripheral to generate the correct sequence (tightly in step with the QSPI), then mux the pin back to the QSPI pin once the opcode and address has been sent (either internal or external mux) - that's the level of complexity that we'd be OK with.

We'd want to avoid solutions with a large BoM cost overhead (eg no FPGAs pretending to be an SPI flash chip!).

RE: Driving high-resolution displays over QSPI

Håkon Alseth — Mon, 06 Feb 2023 08:27:50 GMT

Hi,

Using the QSPI for a non-QSPI-NOR device is not trivial, as the peripheral has been designed for NOR operation, as also described in the post that you linked to:

[quote user=""]The closest post I managed to find is here: RE: QSPI disable addressing but it seems like that wasn't resolved.[/quote]

If you have to send large amount of data, I would recommend that you look at the SPIM3 peripheral (SPIM4 on nRF5340), which is a normal SPI peripheral with 32M mode available.

Kind regards,

Håkon