Writing image data to serially connected (SPI/I2C) displays from a microcontroller is easy enough these days, courtesy of standards defined by the MIPI Alliance, yet there are some gotchas in it which may catch someone using it unaware. [Larry Bank] wrote up a good summary of how one can get maximum performance out of such a display link.
At the core is the distinction between pixel data and command transmissions. The change from command to pixel data mode requires signaling, which takes precious clock cycles away from transferring pixel data between the MCU and display. The common MIPI DCS instruction set allows for a big reduction in needed data transfers by allowing parts of the display to be addressed instead of requiring a full refresh. Yet by not properly segmenting command and data transfers, one ends up unnecessarily slowing down the process.
The result is that one can run something like a Pac-Man emulator on an AVR MCU with a sluggish 320×480 SPI LCD at 60 FPS, as one can see in the video that is embedded after the break. Check the article for another demo video as well.
(Thanks to [nebk] for sending this in)
That “AVR MCU” from the video has a raspberry logo on the back…
Yes, the video is of a RPIZero connected to a very slow 480×320 SPI LCD. Not sure why Maya thought it was an AVR. The point is that the display in that configuration can only handle a slow SPI signal, but with some clever dirty rectangle updates you can do “interesting” things with it.
> Not sure why Maya thought it was an AVR
The article says that you can do it with an AVR, and then shows a video with a Pi. Presumably the paragraph being right above the video made them think the paragraph described the video.
Pretty much, yes. The first assumption is that the text is a lead-in to the video, so when it’s said that it’s an AVR, it’s an AVR.
> The first assumption is that the text is a lead-in to the video
What? Literally, from the article:
> … as one can see in the video that is embedded after the break.
I updated the article to reduce the confusion. My point was that if the CPU is limiting the SPI speed, or the display is limiting the SPI speed, you’ve got basically the same problem and you can work around it the same way.
MIPI LCD connection doesn’t have anything to do with I2C or SPI. Strange article…
Actually it does. The command sets of serial OLED/LCD displays are based on the MIPI display spec/commands.
That could be the case. But I am not sure if a MIPI display also has an internal framebuffer like the SPI displays do. So the framebuffer fill commands that are described are probably not even possible on most MIPI displays.
Eh? A link to a document behind a pay-wall? And an admittedly interesting article which just states without any proof or reference that SPI-controlled displays implement the DSI command set.
Not impressed.
I have also no idea what does a SPI connected LCD have to do with MIPI. MIPI is everything but simple to use proprietary standard that you have to pay big bucks to get access to. And has nothing at all in common with SPI, apart from being a serial connection. What a confused mess!
Well, the only MIPI relevant bit in the article is this:
“The commands and features are based on the MIPI Alliance command set. Each manufacturer has variations, but the concept is the same. ”
So in other words – “the LCD I am using has a controller that happens to implement something inspired by MIPI DSI and allows a partial screen update. Another LCD/controller may or may do it and/or you will need to sacrifice your first born while waving a rubber chicken to get it to work.”
That’s not to diminish the usefulness of the blog post linked but to say that: “Writing image data to serially connected (SPI/I2C) displays from a microcontroller is easy enough these days, courtesy of standards defined by the MIPI Alliance, …” is nuts.
That is a fascinating read. Thanks, Larry, for writing it up. I’m going to try speeding up some of the obviously slow demo code I’ve found via HaD recently.