[fermienrico]

There is a weird spot in the display market that is painful as a embedded developer:

Displays under 400x240 pixels, usually the gfx buffer can be managed in the ram of the MCU. Nothing fancy needed, can get decent framerate on SPI bus running at 16 MHz. Anything above this range gets super ugly: no good displays exist and if they do, they're expensive or outdated (800x480 resolution is basically impossible to obtain). Furthermore, driving this display requires crazy shit like multiple SPI channels (QSPI), or some neutered version of DSI protocol...impossible to find docs for and if they have docs, theyre in Chinese.

Then there are ultra high resolution displays, for e.g. cell phone market or laptop screens. You're now looking an entirely different beast. MIPI/DSI hardware support is required and a bunch of NDAs, need dedicated GPU and a proper linux running.

Ideal display tech would be 5"inch diagonal, OLED (low power consumption), 800x480 (or similar) and can be run using ARM Cortex-M4 or similar microcontroler arch. That would open up opportunities for so many device categories that doesn't exist today. Imagine a VT100 terminal clone running on 8" 1024x768 resolution screen with a cheap ESP32 + display driver chip. Or a slightly more beefy Cortex-M7 running zephyr/linux. So many things we could build.

[nrp]

It's an interesting challenge, but MIPI DSI is sort of the right interface for small size displays too high resolution to drive with SPI. There are a range of Cortex-M4 and M7 MCUs that have DSI output (e.g. https://wiki.st.com/stm32mpu/wiki/DSI_internal_peripheral). The solution is probably just better documentation for the panels and their DDICs.

[cxcorp]

Oh wow, I didn't even know ST had a wiki! I wonder if they also have a section on the STM8 family?

[exged]

Aside from very simple use cases, you'd probably struggle to render 800x480 or 1024x768 frames on an MCU. At 1024x768 especially, the pixel rate (47 MP/s at 60Hz) and framebuffer size (2.3MB at 24bpp) are just too big even for large MCUs.

APs are the right tool for the job. It's true that for hobbyists, documentation is lacking and DSI is complex to get started with. The best solution would probably extend DSI with something like EDID. DSI displays can then be plug-and-play (like HDMI / DP) using an universal driver.

Another option is eDP, but it's not so common on cheap APs or screens.

[jlokier]

The last time I built something with a small display, the CPU-and-on-board-RAM combo didn't have enough room for a framebuffer. But it did have multiple cores, and each of those had multiple hardware-multiplexed threads for real-time processing. Most of the threads were devoted to audio DSP and maxed out.

It was fun developing a little algorithm to stream out full rendered frames in real time, bit-banging 16-bit colour over SPI at its max frequency, while rendering and compositing from an object tree with fonts, textures, gradients, blending etc without ever storing more than a few scan lines worth of pixels. Intermediate pixels and blending states were stored in an ever-moving queue to account for multi-pass rendering and the different timing between the rendering thread, which blended in each item at whatever speed could be done, and the bit-banging SPI thread which formatted the pixels into the strange bit order needed by the display. The bit-banging thread needed perfect, sustained timing as a single glitch would crash the display.

When all the complications were working perfectly, it just looked like a mundane but smoothly animating display, as if it had a boring GPU and framebuffer and some kind of clean GUI.

[davman]

Does this help? https://www.buydisplay.com/5-inch-tft-lcd-module-800x480-dis...

[von_neumann]

Have you used it?