this is a slow motion video of an ice machine interface (lol, sorry) and i wonder..
can someone smart please explain to me why it draws like this? with seemingly diagonal lines?!
@cabel What you’re seeing is a portrait screen that’s mounted sideways, so that it refreshes individual vertical lines from left to right, while the frame buffer is upright (landscape). The screen refresh cycle collides with drawing to the frame buffer because they are not double buffering, giving the diagonal line effect
@cabel It was likely expected to complete the drawing in the vsync interval, which would fix this, but got desynchronized somehow. Or maybe they just didn’t care.
@shac @cabel from my experience with embedded systems like these (card machines in my case, specifically), the display is in a controller of its own with no type of buffer at all. the microcontroller tells it to draw shapes and it just spits it out to the display because neither the display nor the controller have enough RAM to keep a screen buffer, so you see it all drawn in real time.
as for the weird order, a sideways orientation like you said is usually the case
I've been playing with little LCD panels like this a lot lately. 🤣
The SPI bus is also slow(ish). Using a Raspberry Pi Pico 2 (released last year) it takes about 46ms to update this 240x240 pixel display using a 16-bit (RGB565) colour space.
Using an Arduino Nano ESP32 (released less than 2 years ago) it takes about 24ms to do the same. A 60Hz display update rate means the LCD controller will interrupt the external microcontroller every 16.67ms, so each of the microcontrollers I'm using won't be able to transfer the entire image without 2-3 interruptions!!
And the ice cream machine's microcontroller is probably older and slower... 🍦
Creating graphics can be sped up by drawing images into a frame buffer in the microcontroller, and then transferring the entire image at once to the display controller over SPI. This is programmed in MicroPython using its software framebuffer.
The ice cream machine looks like it's drawing each of the graphics primitives directly to the display controller which definitely slows things down.
The other way to speed up the display is to only change little bits at a time... it makes for a fun little break-out game. 😁
@mavica_again @shac @cabel These small displays have their own built-in display controller as maple said, and it contains enough display RAM to store the entire W x H pixel dimensions of the image.
That display controller is being driven by another microcontroller, either over a parallel bus or an SPI bus. Due to I/O pin limitations and ease of connection handshaking, SPI is often the preferred bus, but the parallel bus can (optionally) make use a display refresh output signal so that the microcontroller can update the display controllers image RAM while the display controller is not accessing the RAM update the image on the LCD panel.
When not using the refresh signal on the parallel bus, or when communicating with the display over SPI, the display controller will interrupt the data transfer every 1/60th of a second (or whatever it's refresh rate is) to update the image on the display. What you end up seeing is 'tearing', the microcontroller being out of sync with the display controller.