How easy is it to add models?

[yanshay]

I'm considering getting boards with ST7796 and ILI9485 displays. I see here there's support for ST7789 and ILI9486. I think the difference is screen size/resolution but maybe there's more to it. How simple would it be for me to add support for those displays based on the code available here?

[almindor]

Both these models are already in mipidsi and should work fine.

[yanshay]

Both these models are already in mipidsi and should work fine.

Where, I can't find them. Shouldn't there be a Builder with their codes at https://docs.rs/mipidsi/0.7.1/mipidsi/struct.Builder.html ?

[almindor]

Both these models are already in mipidsi and should work fine.

Where, I can't find them. Shouldn't there be a Builder with their codes at https://docs.rs/mipidsi/0.7.1/mipidsi/struct.Builder.html ?

https://github.com/almindor/mipidsi/blob/master/mipidsi/src/models/st7789.rs and https://github.com/almindor/mipidsi/blob/master/mipidsi/src/models/ili9486.rs

For builder you can use Builder::st7789(di)...

[yanshay]

I am aware that 7789 and 9486 are available in mipidsi.

I'm looking for 7796 and 9485. Similar numbers but still different. Or maybe they are fully compatible even though the resolution is different?

[almindor]

I am aware that 7789 and 9486 are available in mipidsi.

I'm looking for 7796 and 9485. Similar numbers but still different. Or maybe they are fully compatible even though the resolution is different?

Oh lol :facepalm:

Numbers are hard to read haha. Yes, they should probably be very close, I'd check the framebuffer and display sizes and try using the existing models first. If they "just work" (tm) perhaps we can just make it into a doc entry.

[rfuest]

Does the ILI9485 even exist? The only references to that chip I found were for one ESP32 based module, but no datasheet. Perhaps it was just a typo in a product listing or datasheet for that module. If it does indeed exist, the difference between the 9485 and 9486 might be similar to the difference between the 9341 and the 9342, where one is 320x240 and the other 240x320 pixels.

If you intend to use an off the shelf board that already contains a microcontroller and a display you also need to make sure that the display isn't connected via a RGB or DSI interface, which aren't supported by this crate. With these higher resolution displays you are more likely to encounter these interfaces and not only SPI and parallel.

[yanshay]

ILI9485 exists, I've seen quite a few references to its existence other than on boards. The most technical one I found is https://github.com/Bodmer/TFT_eSPI/discussions/2336 which indeed mentions parallel RGB interface.

As I explore for the right board for what I need I'm getting a bit confused. Maybe you can help.

1. Does driver (ILI9485/ST7796/etc.) define whether the interface is parallel or SPI?
2. RGB is parallel interface, right? In such cases is it the MCU that is doing the parallel or driver? And if the MCU - is there some RAM between the MCU and the display or does the MCU need to feed data to the display continuously as the display is scanning (so taking a chunk of the CPU capacity)?
3. I've seen reference for example to 8080 (parallel) interface on some boards and when I looked it up I saw it can work together with ILI9341 which supports SPI (serial) (https://www.displaymodule.com/blogs/knowledge/the-interface-of-8080), so in such case the MCU communicates SPI with the driver and the driver communicates parallel with the display?
4. Does parallel end up being faster than SPI for example? If it does, at what resolution it becomes meaningfully different?

[almindor]

ILI9485 exists, I've seen quite a few references to its existence other than on boards. The most technical one I found is Bodmer/TFT_eSPI#2336 which indeed mentions parallel RGB interface.

As I explore for the right board for what I need I'm getting a bit confused. Maybe you can help.

1. Does driver (ILI9485/ST7796/etc.) define whether the interface is parallel or SPI?

No, that depends on the wiring, some models support multiple interfaces, or there are instances made for different interfaces. It depends on which one you have.

2. RGB is parallel interface, right? In such cases is it the MCU that is doing the parallel or driver? And if the MCU - is there some RAM between the MCU and the display or does the MCU need to feed data to the display continuously as the display is scanning (so taking a chunk of the CPU capacity)?

The driver always "drives" the data, the MCU "provides" access to the interface, in our case it's always via the DisplayInterface crate/traits.

3. I've seen reference for example to 8080 (parallel) interface on some boards and when I looked it up I saw it can work together with ILI9341 which supports SPI (serial) (https://www.displaymodule.com/blogs/knowledge/the-interface-of-8080), so in such case the MCU communicates SPI with the driver and the driver communicates parallel with the display?

In some cases there are SPI -> parallel transofrmations done in hardware via shift registers directly on the display board (I have one such). From your/driver perspective it's just SPI.

4. Does parallel end up being faster than SPI for example? If it does, at what resolution it becomes meaningfully different?

I'm not sure tbh, it depends on max speeds, format etc. I suspect SPI would win in the end for most cases.

[yanshay]

Thanks!

The driver always "drives" the data, the MCU "provides" access to the interface, in our case it's always via the DisplayInterface crate/traits.

In case of parallel 8080 will I be able to use display-interface-parallel-gpio then?

If you intend to use an off the shelf board that already contains a microcontroller and a display you also need to make sure that the display isn't connected via a RGB or DSI interface, which aren't supported by this crate. With these higher resolution displays you are more likely to encounter these interfaces and not only SPI and parallel.

Is that because RGB is different than 8080 (though both are parallel) and the display-interface-parallel-gpio don't support RGB? At least not yet (but probably could?)

Specifically, this display seems interesting https://www.antratek.com/media/wysiwyg/pdf/WT32-SC01-Plus-V1.3-EN.pdf, use ST7796 using 8080 interface. If my understanding is correct I just need to figure if 7796 can be added on the basis of this crate, and the display-interface-parallel-gpio will deal with the 8080 part, right?

[rfuest]

ILI9485 exists, I've seen quite a few references to its existence other than on boards. The most technical one I found is Bodmer/TFT_eSPI#2336 which indeed mentions parallel RGB interface.

But this also references the same ESP32 board I mentioned in my comment.

Is that because RGB is different than 8080 (though both are parallel) and the display-interface-parallel-gpio don't support RGB? At least not yet (but probably could?)

Yes, RGB and 8080 are completely different and only 8080 is supported by this crate. The RGB interface is only carrying the pixel data, similar to a digital version of VGA with signals like VSYNC and HSYNC and the configuration is still done via SPI. Displays with RGB interface are typically driven by dedicated hardware in a µC, like the LTDC in STM32s or the LCD_CAM in ESP32s.

Specifically, this display seems interesting https://www.antratek.com/media/wysiwyg/pdf/WT32-SC01-Plus-V1.3-EN.pdf, use ST7796 using 8080 interface. If my understanding is correct I just need to figure if 7796 can be added on the basis of this crate, and the display-interface-parallel-gpio will deal with the 8080 part, right?

That's correct, this should get you started, but the bit banging implementation in display-interface-parallel-gpio wouldn't be super fast. A custom display interface, which uses the LCD_CAM module in I8080 mode could be used to accelerate the communication to the display.

[yanshay]

That's correct, this should get you started, but the bit banging implementation in display-interface-parallel-gpio wouldn't be super fast. A custom display interface, which uses the LCD_CAM module in I8080 mode could be used to accelerate the communication to the display.

• Would it be slower than SPI or just slower than what I can expect from an even better interface/implementation?
• From the name it sounds like LCD_CAM is for direct camera integration. Is that also for general use (my use would be UI framework that redraws the entire screen every cycle and does UI animations for gui components).

[rfuest]

Would it be slower than SPI or just slower than what I can expect from an even better interface/implementation?

I don't know. But for a 16 bit bus the overhead of using the generic parallel display-interface is pretty high, because every bit needs to be set individually. This means that if setting a GPIO pin is faster than 1 cycle of the SPI clock the parallel interface should be faster.

• From the name it sounds like LCD_CAM is for direct camera integration. Is that also for general use (my use would be UI framework that redraws the entire screen every cycle and does UI animations for gui components).

The LCD_CAM module can run in different modes and either reads from a camera or drives a display. The details are described in the ESP32 technical reference manual, but the TLDR is that you can point it to a buffer and it uses DMA to update the display via a i8080 interface or continuously scans out the image on a RGB interface.

[yanshay]

The LCD_CAM module can run in different modes and either reads from a camera or drives a display. The details are described in the ESP32 technical reference manual, but the TLDR is that you can point it to a buffer and it uses DMA to update the display via a i8080 interface or continuously scans out the image on a RGB interface.

So basically, to use LCD_CAM I'd need to:

1. Setup memory space for the full screen buffer at a known address
2. Setup LCD_CAM with the proper memory address
3. Instead of my current code that bridge between the UI framework and mipidsi (this crate) to pass data to the display, I would need to simply write the data into the memory buffer and trigger the LCD_CAM to transfer the data using i8080 interface

Correct?

[rfuest]

Correct?

That's roughly how it should work. But you'll still need to initialize the display before you let the LCD_CAM handle the display update. You can use the mipidsi crate and display-interface-parallel-gpio for the init and switch to LCD_CAM after the display has been inizialized.

[almindor]

Just doing some housekeeping on issues, how are we here, do you plan to continue work on this?

[yanshay]

Here are a few updates:

1. I can confirm that 7796 works just fine with the existing 7789 here
2. As stated above, it is pretty slow due to display-interface-parallel-gpio. A lot of that slowness is due to Rust abstraction that goes beyond the pure io.
3. I was able to use mipidsi on top of display-interface-parallel-gpio for just initialization and then do the mass data send to the display using direct esp32 outputs, optimized for the specific board I'm using (some internal capabilities esp32 has which depends on exact gpios used) to get much better fps rate.
4. Still, that wasn't good enough, so I searched for lcd_cam and lately have been working with a contributor on esp-hal who developerd that driver there (exactly today code merged), with that it's a perfect solution, I reached the point where display is not the bottlneck, only the rendering.

From mipidsi perspective, as said in 1 above,7796 is supported using 7789, at least the subset of commands I needed work.

[almindor]

Thanks for the info.