libili9225 - Controlling a ILI9225 SPI display with your Omega2

Maximilian Gerhardt

This is the second release in a series of at least 4 projects, coming over the next week. First release was here.

The libili9225 is a C-library with which you can controll ILI9225 based displays.
Github page: https://github.com/gamer-cndg/omega2-ili9225

Functions of this library include:

all pins of the display can be connected to any GPIO (thanks to the bit-banging of the spi-gpio-driver)
drawing text with different fonts, sizes and colors
drawing shapes (lines, circles, triangles) either filled or outlined with a color
changing the orientation of the display (portrait / landscape)
turning the display on and off (either by LED GPIO pin or SPI commands)
modfying the internal framebuffer directly, or drawing from an external frame buffer
executing a graphics demo

The library works mostly on the local framebuffer and transfers it to the display via a ILI9225_CopyFramebuffer() call to the display.

Due to the errors and issues with the OnionIoT provided spi-gpio-driver package, this library also suffers from the following things:

colors might be drawn wrong (in particular, the MSB of the red value every 8 pixels). This is due to a bug in the Onion's SPI interface.
drawing is extremely slow. 1 - 2FPS slow. This is due to the SPI driver only accepting transfers of at maximum 16 bytes, whereas the framebuffer is about 76 kilobytes big. The ESP32 (240 MHz CPU) can do 60 FPS with a 40MHz DMA-backed SPI driver.

However, if you just need your Omega2(+) to display some simple, slow-changing graphics on a 5 US dollar, 176x220, 16-bit color display, this library is your friend.

display

Happy Hacking!

Alfonso Blanco

Hello Maximilian,

Awesome! This is super useful.

Im trying do to kind of the same but for a ILI9341. It's essentially the same, but changing the commands codes.

What I've been trying to overcome (without success) is the malfunctioning of the SPIs MSB. I have had a peek at your code and it's mostly similar to mine. How did you overcome this issue?

luz

Great work! Thanks for porting the library!

Just out of curiosity - have you tried the hardware SPI? There are issues with that, too (MT7688 hardware has a bug in full duplex transfers, and the driver needs a patch to at least support half duplex). The speed should be much better here (after all, that SPI bus is used to get data from and to the flash).

Maximilian Gerhardt

@Alfonso-Blanco said in libili9225 - Controlling a ILI9225 SPI display with your Omega2:

Hello Maximilian,

Awesome! This is super useful.

Im trying do to kind of the same but for a ILI9341. It's essentially the same, but changing the commands codes.

What I've been trying to overcome (without success) is the malfunctioning of the SPIs MSB. I have had a peek at your code and it's mostly similar to mine. How did you overcome this issue?

The funny thing is that for this particular display the bug doesn't matter so much -- when writing to registers, conveniently, the address of the important registers of the ILI9225 are in the range where the SPI transmitter doesn't exhibit the MSB bug. At the end of the initialization sequence though (setting the gamme curve), the bug occurs, doesn't however cause any harm. I've thought about a workaround for this, but didn't implement it yet (because it works without it it, too) -- You might be able to group register writes and such in groups of at maximum 16 bytes, and only the MSB of the first byte might be corrupted of it's from 0x40 to 0xbf. So, if the first byte isn't in that range (known good value), then the entire transmission will be bug-free. Thus you may be able to correctly write to a register between 0x40 and 0xbf be first placing a write to a lower reg (0x00-0x3f e.g.). Oh, and another hint: You can pretty much drop-in the initialization routine from here if that's where you're stuck

@luz said in libili9225 - Controlling a ILI9225 SPI display with your Omega2:

Great work! Thanks for porting the library!

Just out of curiosity - have you tried the hardware SPI? There are issues with that, too (MT7688 hardware has a bug in full duplex transfers, and the driver needs a patch to at least support half duplex). The speed should be much better here (after all, that SPI bus is used to get data from and to the flash).

Please, by all means, if you have any resources on how to easily use the hardware SPI interface on an Omega2+ from C, preferably without having to recompile / patch the kernel or firmware from scratch, I'd like to hear it. All I found was the spio-gpio-driver kernel module and library. I'd be great if you made your own project page about that if you succeed. This and another part of this project will benefit greatly from a faster half-duplex (TX only) SPI.