Re: ST7789V2 LCD Controller

[afoken]

Some notes on connecting a display to the Raspi. The Raspi has three (or four) conventional display interfaces:

• The most obvious one is HDMI. Connect any cheap box with HDMI input and you'll get an image. Behind the scenes, HDMI is quite complex, but there is so much ready-to-use hardware that you don't have to think about it. The HDMI output is controlled natively by Linux, it looks like a cheap graphics card on a PC to Linux. Some Raspis even have two HDMI outputs.
• There is a composite video output that you could connect to many, many old TVs and many monitors. It is an analog signal, which limits the usable resolution to about SDTV. Like the HDMI output(s), Linux and the graphics hardware take care of this output. The output is on the headphone jack, on a dedicated cinch connector, or on some pads, depending on the Raspi model.
• There is a DSI (Display Serial Interface) on a flatflex connector. It is designed to control "embedded" displays, typically with a resistive or capacitive touch interface (connected via I²C). Like HDMI, Linux and the graphics hardware take care of this output. It basically behaves like a laptop or tablet display.
• The graphics hardware can also use the GPIO pins with a hand full of resistors or a better DAC to generate a VGA RGB signal. This costs you all available GPIOs, so you rarely go this way. But as before, Linux and the graphics hardware take care of the VGA output.

The ST7789V2 is controlled via SPI, using a custom protocol (that I seem to remember from similar displays at work). The Raspi graphics hardware won't help you with that. You could write a frame buffer driver for the Linux kernel, or a "graphics card" driver for X11 or Wayland to support this display. Or you directly write pixel from your application via SPI to the ST7789V2, like you would do on an Arduino or any other microcontroller.

<Update>

Looking at the website once more, it seems soneone actually has implemented a kernel mode framebuffer driver for that display, using several tricks (DMA, partial refresh) to get reasonable frame rates over an inadequate interface.

</Update>

Having an independent display may be useful (no bluescreen on that display), but on a Raspi, I would use DSI or HDMI. There are tons of well-tested code to handle everything to draw on a DSI or HDMI display, including 2D and 3D acceleration, font rendering, and so on. No need to reinvent the wheel.

Alexander

[Bod]

The most obvious one is HDMI

I'm using a RaspberryPi Zero which, unlike it's bigger brothers, doesn't have HDMI :(

Space is a bit limited on this project, hence the Zero and a tiny display.

[marto]

"I'm using a RaspberryPi Zero which, unlike it's bigger brothers, doesn't have HDMI"

You should read the specs of what you bought, this is wrong.

[Bod]

this is wrong

Care to explain what is wrong and why?

The RaspberryPi and the display work together...the C demo program shows this to be the case. There are Python examples that drive the display (I haven't tried these but I've not seen lots of people complaining they don't work).

If it can be done in Python, surely it can be done in Perl...

Or did you mean something else is wrong? Perhaps you feel I am using the wrong language?

BTW - I didn't set out to use this device. I was gifted one and felt it could be an interesting challenge to use it for a useful project.