The time and effort you put into all your videos is much appreciated

Nice video, just what I was looking for! Very informative and to the point. I just started with the Pico a month or so ago, I've tried out various bits of hardware, and your display buffer solutions are top-notch! Appreciate all the work you put in to this.

Thanks very much for this video and the continuing series. I dabbled in electronics many years ago, then went wholly into UNIX and Linux computing (and retro gaming) but you and a couple of other YT creators have really got me back into electronics again.

This one of the coolest videos and content creators I have ever seen on KZfaq. There is massive gimmickry all over KZfaq and very little real stuff like this. Explanation of the whole frame buffer concept was awesome. I have purchased a SPI LCD last week and I am going to dabble in the code very soon. Respect !!

Hey! I just paused the video real quick because I realized, I don't think I've thanked you yet! In the last few weeks, I've spent hours and hours watching your youtube tutorials, many of the same videos more than once, and have been using all of your help to start programming my Pico project. Thank you SO much, your videos are so easy to follow, your explanations are wonderful, and I just couldn't be more appreciative to have you and your guides as a resource! Thanks man!!

Very thoughtful way to achieve the desired fps throughput. Appreciate the effort put to explain the details.👍👍 👍

I love how you explained this - especially with the graphics.

the display i got was not compatible. ordered one ST7789 based to test your code. One of teh best video on youtube on the argument. Subscribed the channel. Thumbs up!

As an absolute beginner I can't really understand it but I'd like to commend you on your hard work. It's a shame you have so few subs.

Simply awesome, thank you! 😊🕊

great video much to learn from this ❤

Gracias por tu vídeo, me ayudó mucho en un proyecto que tengo en mente y fue muy fácil adaptar su uso a la librería del display ST7735 de 1.8 que planeo usar como reloj. Saludos desde México.

Wow, double buffering 😂 that takes me back 😁

Very cool!

I strongly suspect the PIO alone can convert an RGB332 framebuffer up to RGB565 by just shifting out the MSBs and zero padding. It is fast-enough in C, though. You can do per-scanline conversion into a buffer and transfer it asynchronously with DMA. It's near-enough cost neutral, since your pixels are being converted while the previous batch are transferred. There's a PIO interface in MicroPython that might actually make PIO conversion possible without delving into the horrors of writing MicroPython C extensions (or writing C outright).

Did you try to update by slices or blocks? as an old CRT TV? For example, you could make an image block of 320x60 pixels for the first layer with the frame buffer method and them send it to the display to show it in the upper quarter of the screen. After that, make the second layer and send it to fill the second quarter of the screen. Make the same to the third and fourth. When you start again with the first quarter, you just need to overwrite the previous image block with the new one. You would need only 38 kB at a time.

when you do the connection images with the pico you should also point out that scl is also clk and sck and miso and that sda is mosi and sci etc rx tx as some boards dont show what it show in the driver even your image now shows lcd clk connected to gp10and the driver doesn't have a clk pin assignment so if people are learning this will confuse them

Great stuff. What's micopython like at handling rom based look up tables? Thinking 4 or 8 bit pallet.

I have a question: how would you reduce to 4 bit/px on the 1.14 display? for fbuf variable i thought messing with framebuf.GS4_HMSB, the 4bit format, instead of .RGB565 but im not sure about that or what to do to the bytearray equation or other variables.

Is it possible to run multiple ST7789 with this driver, I have some 16Mb Pico clones with plenty of RAM for framebuffers and I need to run 8 displays. I have 3 running on a Teensy 4.1 but I've ran out of memory.

If the colour translation from 8 but to 16 bit involved only bit moved, could the PIO do it with the state machine upon transmission?

Is it possible to render a full image at 15 frames per second with the ili9341 display? And if not, is there any sort of tutorial for programming the ili9341 screen with C or C++?

thanks for the helpful vids - question for you: when I use the color565() function with the display (not using framebuffer) the colors are correct. If i use the buffer and pass in the color565() function, the colors are different/incorrect. any reason why that may be the case?

im using a waveshare display that require the st7789 driver and i seemed to have everthing uploaded correctly. when i do import boxes buffer i get this.. SPI(1, baudrate=31250000, polarity=1, phase=1, bits=8, sck=10, mosi=11, miso=8) 51.27% 32.67308 32.57108 .. in REPL which tells me its running and is reporting fps but the screen is off, no backlight or anything. is there a way to turn the screen on or should it be turning on just from having the pico connected to it and connected to power?(which would mean my display is a dud?)

Amazing video! Maybe a stupid question, does this work on an Arduino too?

Ok i've got the display. 240*240 ips based on st7789 .... now i got pin1=gnd, pin2=VDC Power 3.3 V, pin 6=DC. I can imagine pin 5= RESet, but how can i map pin 3=SCL, pin4=SDA and pin 7=BLK to you ILI based sck, mosi, miso, cs=Pin(17)?

There seems to be a missing part of the st7789 driver file, which is having problems at run time。 Traceback (most recent call last): File "", line 130, in File "", line 75, in main AttributeError: 'ST7789' object has no attribute 'fill'

Sir i would like to build a hand held nes emulator with the pi pico and one of these little red displays...i cand find anyone who has done this. I have already built the emulator with the pico pi but getting it to work with the little display has got me stumped....any thoughts on the matter?

Hi. Would you mind making a new 2-3 minute KZfaq video explaining what a framebuffer is, how it works, the benefits and why it is used - show the bouncing boxes, and the illustration of the Pico connected to the framebuffer and to the screen LCD or other). i.e. Just a sub-set video of this longer video on your channel (without the driver and python info). I would like to put a link to this new video on a Microcontroller forum I'm a member of, and I think it would be of value to the other members. Many thanks.

Good to know I'm not the only one who's tried a framebuffer approach to speed up display rendering. One comment/question, though. It's hard to tell from this video, but how bad is the screen tearing? I've written a super simple test in C that makes use of a framebuffer and DMA. It fills the entire screen with one color, waits a second, changes to another color, rinse and repeat. On the surface it works as designed, but if one looks closely I can see the display "actively refreshing" -- and it's particularly apparent when the previous color and the next color contrast. Have you seen this as well? Is there a way to mitigate it? Or is it likely simply a result of the display having its own SRAM (as opposed to writing directly to VGA/DVI where the display is expecting constant updates and does not "latch" the display data)? **EDIT** Please ignore this. For those who are having a similar issue described, check the CASET and RASET commands in the ST7735R datasheet. It appears my computed 32K of required memory (for 128x128@16bits) fills the screen. Thus, I was actually rendering twice in one pass. Some rows of memory are rendered offscreen so adjustments using the aforementioned commands are necessary. Still investigating why it won't fill the whole screen in 32K (I had to bump it up to 40K to get it to fill). Much less tearing seen.

Nice project! Now,how to create a PDA-like system with SPI LCD + RP2040.

When I first started with the ILI9341, I used the Teensy and Adafruit library's. It was not very impressive! I then looked at their text/font writing code, and they were using pixel writes to do fonts! Awful, lazy coding. I wrote my own routines using block transfers for each character. I was able to obtain a 17x performance increase. The problem for me was the characters appeared upside down and backwards because of the way fonts were stored in flash. Once I re-ordered the fonts, everything was fine. I wonder if you have run into this (have 'they' re-written the text routines)?

Is it possible for the Pico to read a video file from a micro SD card and display it on a LCD without needing to be connected to a PC? I just want to be able to flip a switch to turn a standalone Pico on and have it start playing the video file automatically. Is this possible? Sorry for the newbie question.

I tried it on my esp32, and it works fine, but it turns out that i have not enough memory to allocate whole buffer, so i rendered only a part of my screen. Can i do something about it so i may render the whole screen or i clearly can't bcs of having not enought memory ? Btw video is great and i learned a lot

I've been playing with this and I noticed that the driver function "color565()" returns color in brg fornat. The problem is a big-endian/little-endian thing. If you change the color565 function like this it returns rgb like it should. ''' display is big-endian, pico is little-endian ''' def color565(r, g, b): val16 = (r & 0xf8) 3 # swap the bytes: return (val16 >> 8) | ((val16 & 0xff)

ok, i mapped the 240x240 st7789 with spi1_sck=10, spi1_mosi=11, st7789_res = 12, and st7789_dc = 13 Modified both screen_width/heigh to 240 (and the buffer width/heigh to 240), but now i got a MemoryError: memory allocation failed, allocating 115200 bytes

Doesnt seem to be working on thonny, I just get an error.