SPi Display Questions?

[DavidS]

Seeing more and more of these SPi displays on the market, many with between 30MHz and 50MHz max for SPI, I am wondering if it would be worth playing with these for serious projects?

I see some of the 50MHz versions as large as 7 inches with advertised resolutions of up to 800x480. It seems to me that if one was able to get 100% throughput that would give a full screen refresh (no dirty rects) of only around 8FPS, unless I am missing something.

With the more common 480x320 displays that seem to be out there, with a 30MHz SPi clock it seems that the maximum full screen redraw rate would be about 12Hz.

I am wondering what others experience is with these before I go and order one. I find mixed opinions when searching, and nothing yet on pushing out the SPi signal directly (seems like everyone is relying on a Linux driver).

It seems to me that if it is reasonable to push these past 20Hz full screen redraw rate this could be an opertunity for baremetal. This could give us something that would allow us to write our own bootcode.bin and start.elf replacements and still have display output available. It may take a while to write enough to implement a good subset of the functionality of what we have with the current bootcode.bin and start.elf, though what programmer does not want the ability to have one example of each of there computers running 100% there own code?

So what experience do people have in directly controlling these displays (No Linux)?

[DavidS]

Also if we remember that it will likely be 30 years or more before the HW of the RPi 1 is pushed to its limits by the programmers that stick with it, the sooner we can start on playing with writing 100% of our VC4 code the better.

People were still pushing new limits with the stock Commodore 64 in 2012. We still today see new demos and games on the Atari 520STf that push the abilities further than ever before on the stock HW. We are still seeing people push the original Amiga 1000 further than ever before, in 100% stock HW.

Just 20 years ago we would have never thought a complete playable good quality racaster would be running on a Commodore VIC-20, today we have 3 of them. Same goes for good racasters on Stock C64, Atari 800, and many other 6502 based computers.

As such it is reasonable to assume that we will not truely know what the RPi is capable of for another 30 years or more. Though it will be much longer if we can not find a way to truely play with the VC4, without its RTOS.

[DavidS]

It apears that people are managing to get some good results with these displays in Linux. Still not seeing any information on directly playing with these, other than the datasheets.

As the potential results are fairly good I guess I will have to order one and play with it, see what I can get it to do.

This will be an interesting learning experience for me, I have never played with an SPI display before. I am thinking about one of the 480x320 models that are so common, will check the chip used before purchase to make sure it is one of the ones that have been succesfully run at greater than 60MHz clock rates, as that seems to be the key to decent redraw rates from what I have found.

Ok I guess I will order a few.

Reviside Question:
Anyone that has some experience with programming for these SPI displays, I would apreciate any pointers to good information on how to do this on the bare metal (even if it is just Arduino code).

[ab1jx]

I have an old Adafruit 320x240 but even that is too slow with loops in C. A memmove maybe.

I was looking for something else and discovered there are now 640x480 LCDs still at 2.8 inches. https://www.dx.com/p/geekworm-raspberry ... or-2091293 They're on Aliexpress too but about the same price ($20 US).

I can't tell if they're HDMI or SPI but even the link claims 60 FPS. There are some drivers at https://github.com/tianyoujian/MZDPI

Beware of the "English Manual / Spec No". I think it's SPI since it connects to the GPIO pins.
It's really meant for the Zero.


There's a little more stuff at http://www.raspberrypiwiki.com/index.ph ... or_Pi_zero but they're more evasive than I like about the interface type. They don't even mention color depth, my Adafruit is only 16 bit (65335 colors).

[DavidS]

Thank you for that information. I understand that the refresh is a bit low if you do not overclock the SPI, and that depends on the controller.

16bpp is the default depth for Raspbian framebuffer and X, so it is enough for 99% of all applications.

[Paeryn]

16bpp is the default depth for Raspbian framebuffer and X, so it is enough for 99% of all applications.

The framebuffer used to default to 16bpp but I'm sure it's been 32bpp for ages (couple of years or more).

[ab1jx]

16bpp is the default depth for Raspbian framebuffer and X, so it is enough for 99% of all applications.

The framebuffer used to default to 16bpp but I'm sure it's been 32bpp for ages (couple of years or more).

I was pleasantly surprised when I wrote this
https://sourceforge.net/projects/fbgrad/ but I think the problem goes deeper in this case, like it's a limitation of the IL(whatever) chip that interfaces it.

The speed might have been adequate but at a.cost of almost 100% CPU. The GPU should be doing this stuff.

[DavidS]

16bpp is the default depth for Raspbian framebuffer and X, so it is enough for 99% of all applications.

The framebuffer used to default to 16bpp but I'm sure it's been 32bpp for ages (couple of years or more).

I was pleasantly surprised when I wrote this
https://sourceforge.net/projects/fbgrad/ but I think the problem goes deeper in this case, like it's a limitation of the IL(whatever) chip that interfaces it.

Yes the bit depth is do to the ILI9341, ILI9486, MPI3501, ILI9340, HX8357, MPI3501, and other controllers used in these displays. The redraw speed is limited by data throughput on SPI.

There are some good resources for Linux on these devices used on the Raspberry Pi. For example:
https://github.com/juj/fbcp-ili9341 : Higher redraw speed with overclocking the controller SPi, also uses selective updating to improve overall effective frame rate.

The speed might have been adequate but at a.cost of almost 100% CPU. The GPU should be doing this stuff.

That is the reason that I want to play with the SPi controlled devices. The ability to write a replacement bootcode.bin as well as something to replace the functionality of start.elf means that we can do things in the GPU that are currently more difficult to accomplish.

Unfortunately with the current state of play no one has yet figured out how to get HDMI output working without the Broadcom provided firmware, I do not think anyone has even managed NTSC or PAL composite video out. With SPi we actually stand a chance at running 100% open source systems, as well as being able to do a lot more with the hardware in the baremetal.

[DavidS]

Double post, forum issue well known. Removed redundant repeat post text.

[ab1jx]

Is there a path from the GPU to HDMI if you do GPU assembly language like Herman Hermitage et al? I'd possibly rather learn that than OpenGL https://github.com/hermanhermitage

But yeah, I don't know how it's plumbed. Could be switchable from HDMI to SPI or not, but bit-banging with the CPU mostly just eats CPU. The GPU can do lots of stuff all at the same time in parallel. Of course then you're locked into one GPU.

[DavidS]

Is there a path from the GPU to HDMI if you do GPU assembly language like Herman Hermitageet Al? I'd possibly rather learn that than OpenGL https://github.com/hermanhermitage

But yeah, I don't know how it's plumbed. Could be swithable from HDMI to SPI or not, but bit-banging with the CPU mostly just eats CPU.

No way known yet to enable HDMI without using the original firmware (though you can write GPU code that runs on top of the existing firmware and use HDMI).

The reason that SPi is a possibility is that we can play with the GPIO and other periphials (including SPi) from the GPU without having to deal with what we do not know.

Slightly Oversimplified Description:
The VC4 GPU is a multicore VPU (read CPU enhanced for graphics type operations, specializing in SIMD), multi core QPU that provides a powerful implementation of HW floating point and a good bit more, and some control, bus systems, and other stuff builtin. Put simply it is a CPU that is very good at the kinds of SIMD needed fro graphics operations of all kinds.

The closed source firmware is a Real Time Operating System that provides the interface we use on the GPU (the mailbox protocal, OpenGLES, the ability to run VPU threads, etc).

The unknown is how the HDMI signal is controled. I have been looking forward to seeing someone crack that one for a long time, it has not come yet.

So yes we can run code on the GPU that will end up displaying to the HDMI, though only if we are using the closed source firmware. I personally would much rather have a completely open source system .

[ab1jx]

So don't load the firmware and find a way to make it work without it. I think that's what OpenBSD is doing, it took years before anybody there got interested in the Pi at all because of the BLOBs. Last I knew they didn't have the HDMI working yet. But there's also NetBSD and FreeBSD.

Sounds like the way Compaq wrote a replacement for the IBM BIOS.

[ab1jx]

I asked at http://www.raspberrypiwiki.com/index.ph ... or_Pi_zero
This is SPI? Or HDMI? 16 bit color or 24 or 32?
and the answer I got was

Hello, The 2.8inch screen is consist of display screen and touch screen, The display screen is DPI, and the touch screen is SPI. And the screen is 16 bit color and RGB565 mode.

Best regards,
Cindy

Figures that it's SPI since they don't show an HDMI cable, but maybe they'd just left that out of the picture. For $20 maybe I'll pick one up next payday. SPI is supported in the kernel with a framebuffer? That's 4 times as many pixels as the 320x240 from Adafruit, that's gonna be an awful CPU load on a Zero's CPU.

[Paeryn]

I asked at http://www.raspberrypiwiki.com/index.ph ... or_Pi_zero
This is SPI? Or HDMI? 16 bit color or 24 or 32?
and the answer I got was

Hello, The 2.8inch screen is consist of display screen and touch screen, The display screen is DPI, and the touch screen is SPI. And the screen is 16 bit color and RGB565 mode.

Best regards,
Cindy

Figures that it's SPI since they don't show an HDMI cable, but maybe they'd just left that out of the picture. For $20 maybe I'll pick one up next payday. SPI is supported in the kernel with a framebuffer? That's 4 times as many pixels as the 320x240 from Adafruit, that's gonna be an awful CPU load on a Zero's CPU.

They said the touchscreen is SPI i.e. that thin-film resistive layer stuck to the front of the display that registers where you touched it. The display itself is DPI which the VC4 can output to without bothering the CPU.

[ab1jx]

They said the touchscreen is SPI i.e. that thin-film resistive layer stuck to the front of the display that registers where you touched it. The display itself is DPI which the VC4 can output to without bothering the CPU.

OK, DPI https://en.wikipedia.org/wiki/Display_pixel_interface which is part of MIPI https://en.wikipedia.org/wiki/MIPI_Alliance along with CSI https://en.wikipedia.org/wiki/Camera_Serial_Interface, I didn't realize there was such a thing.

And it has an XPT2046 (datasheet link: https://ldm-systems.ru/f/doc/catalog/HY ... PT2046.pdf)

So this connects to a Zero's SPI0 or SPI1? I guess serial's serial as long as the number of bits and stop bits are right. So DPI can sometimes at least connect to SPI.

compos1_cr.jpg (116.13 KiB) Viewed 3293 times

[Paeryn]

They said the touchscreen is SPI i.e. that thin-film resistive layer stuck to the front of the display that registers where you touched it. The display itself is DPI which the VC4 can output to without bothering the CPU.

OK, DPI https://en.wikipedia.org/wiki/Display_pixel_interface which is part of MIPI https://en.wikipedia.org/wiki/MIPI_Alliance along with CSI https://en.wikipedia.org/wiki/Camera_Serial_Interface, I didn't realize there was such a thing.

And it has an XPT2046 (datasheet link: https://ldm-systems.ru/f/doc/catalog/HY ... PT2046.pdf)

So this connects to a Zero's SPI0 or SPI1? I guess serial's serial as long as the number of bits and stop bits are right. So DPI can sometimes at least connect to SPI.

I think you are getting a bit mixed up, DPI isn't sent via SPI, the SPI is used solely for the screen to tell the RPi where you are pressing.

DPI consists of 24 data lines for colour (though fewer can be used as long as both ends know the bit depth) + 4 (or 6) control lines, the entire colour of a pixel is transferred in parallel every clock. The XPT2046 just handles the touchscreen, it only needs to report the coordinate of where you are touching the screen.

The display itself gets each pixel's colour data directly via 16 GPIO pins and a further 4 GPIO pins for the Clock, Enable, HSync & VSync signals. RPi DPI docs

[ab1jx]

It finally came yesterday, and if they'd been clearer what they meant about the pins not being directly compatible with a Pi i might be ready for it. Instead, after a long wait (weeks), now I have to order something else and wait again.

The display board has 40 pins sticking out, like a Pi has 40 pins sticking out. Seems like somebody makes a double-ended socket for those. But unless you're going to solder it onto your Zero you need something like https://www.newark.com/harwin/m20-61120 ... dp/03M3404 to solder onto your Zero to plug it into. Good excuse to pick up other Pi accessories while you're there. Or you can probably find one cheaper somewhere else, they've been around 20 years or more.

1900788.png (203.04 KiB) Viewed 2849 times

This level of detail about the display would have been good, it came from Newark/Element 14. Again, this is the connector to mate with the display. And it's a 20 pin version. Not exactly a new thing, a hard drive connector will mostly fit, but those are on the ends of ribbon cable and most have a pin (index pin) missing. A hard drive has pins sticking out, the socket end is on the cable. Not that you can't do the reverse, it's just not conventional.

You probably can't unsolder the pins (header) from the display board if you wanted to because the display itself covers the back side where you'd need to unsolder, then it's probably glued to the circuit board. So you need a socket, and soldered to the Zero board. From Adafruit you can buy a ZeroW with pins soldered into it, I don't remember if they offer sockets on them. This is just backwards from everything else.

[ab1jx]

You can get a pretty wide variety (this is from DigiKey) but I thought somebody had a double (back to back) socket. That would plug this display right onto a Pi.

sqconnectors.jpg (143.24 KiB) Viewed 2839 times

https://www.digikey.com/en/resources/co ... connectors

[LdB]

Two 40 pin headers and short length of 40 pin ribbon ... problem solved
Any old IDE cable is 40 pin and correct but may be too long to drive.

[ab1jx]

Two 40 pin headers and short length of 40 pin ribbon ... problem solved
Any old IDE cable is 40 pin and correct but may be too long to drive.

You can cut that stuff with scissors or tin snips and put the connector back on using a vise to keep everything parallel. You can't turn it around though or the pins will be wrong.

Most IDE stuff has a certain pin cut off the male end and a hole plugged on the socket to prevent plugging it in backwards. But re-using a socket should be OK, just look for a little plastic thing in one of the holes and pull it out.

But actually that length might be good if it's going in a case, put the display on the outside or something. I bought cable and connectors for my Pi B, then they went to using more pins, and the B died.

[hippy]

I am wondering what others experience is with these before I go and order one. I find mixed opinions when searching, and nothing yet on pushing out the SPi signal directly (seems like everyone is relying on a Linux driver).

I'm bit-banging an ILI9486-based 480x320 SPI LCD, WaveShare 3.5" etc, and that's easy enough to drive. I'm bit-banging the SPI and in Python so that's incredibly slow. I can't see any reason you shouldn't be able to drive one from within the VC4 GPU.

As for maximum frame rates and getting the system's frame buffer out I have no idea.

The ILI9486 supports 16-bit RGB565 colour, and also 18-bit RGB666 ( sent as 24-bit ), but that's a lot of extra bytes to send for what is likely little gain.

I would suggest get one, bit-bang it in Python, C or Basic, prove it works. Crank it up to use SPI hardware, measure what the frame update time is, determine what maximum frame rates you can get, then worry about moving that into the GPU.

[ab1jx]

I would suggest looking at the link Paeryn posted above
https://www.raspberrypi.org/documentati ... /README.md

I almost never re-read documentation so I didn't know there was such a thing, You shouldn't need to bit bang except as a test. I have an old Adafruit PiTFT https://www.adafruit.com/product/1601 which is serial (SPI)

Uses the hardware SPI pins (SCK, MOSI, MISO, CE0, CE1) as well as GPIO #25 and #24. All other GPIO are unused.

I haven't found a use for it yet, haven't thrown it out but almost. Bit banging that even in C is slow and eats a lot of CPU. And trying to update a normal X screen on it many times a second is absurd. Maybe there's a similar way to get the GPU to do the updates. Adafruit has an image they expect you to download to run it, I had trouble making that do much else. It was hard to take Adafruit very seriously after that experience. That was Model B days, but I've bought a few things from them lately (including Zeroes). This is DPI, not SPI.

But also because there's no direct link from screen pixels to the frame buffer you can pretend it's higher resolution than it is, you just may not be able to read the result. You can (in many cases) pick a higher resolution mode in your config.txt than your display actually can do and it sort of works, which might be handy in dealing with software applications that won't fit your screen. You couldn't do that with CRT monitors, you'd risk burning something out.

[hippy]

I would suggest looking at the link Paeryn posted above
https://www.raspberrypi.org/documentati ... /README.md

Not sure who that's directed at but that is for DPI displays, not the SPI displays which DavidS and I were discussing.

DPI uses a parallel data bus, uses up almost all the 40-way GPIO connector pins, up to 24 GPIO data pins plus control signal pins.

SPI uses a three-wire serial bus plus a couple of control signal pins, can be used with both 40-way and older 26-way GPIO connectors, with other GPIO pins still available for use, providing physical access to them can be obtained.

DPI should give faster frame update times, support higher frame rates and larger display sizes with reasonable frame rates because it is a parallel data bus. SPI being serial is much slower, supports lower frames rates which get lower as screen size increases.

SPI screens can support the system frame buffer, console and desktop display, and that seemed reasonably responsive to me (480x320), but I have no idea of what frame rates that delivered.

My interest is in other than that, using SPI LCD's as information displays direct from within my code, separate to the main display. That's a send once and leave it there task, so I have little interest in frame rates, other than speed of getting the data transferred, and 'slow as hell' is good enough for me, though faster is obviously better.