LT7381 driver

[Tomasz]

Hi,

I'm trying to develop LT7381 driver using SPI interface and framebuffer mode for ESP32. I've successfully  initialized the display by using modified SSD2119 init code but framebuffer implementation seems to be problematic. LT display doesn't use D/C line and additional byte needs to be send  every time to distinguish between data and command bytes. I  hope somebody can give ma a hint because I've stuck right now. I couldn't find any code example for such an interface configuration. All existing gdisp drivers use D/C line for SPI interface, I believe.

 

[Joel Bodenmann]

Hi!

The µGFX GDISP module provides different kinds of driver interfaces. These are listed explained here: https://wiki.ugfx.io/index.php/Display_Driver_Model

The framebuffer model is only one of them. If your display controller doesn't provide direct access to the framebuffer it's usually not the right model to use.

Please don't hesitate to ask if you have any questions!

[inmarket]

Also have a look at the code for an Olimex board. It is lying around somewhere probably in the boards directory in the source code. It also uses a 9th bit instead of a D/C line and was one of the first boards used when developing the uGFX project. 

Of note: This means of communication requires a CPU capable of 9 bit SPI. The standard ST processors don't but SAM processors do. Look at your CPU hardware specs to see if it is supported. 

Also, sometimes the display controller can operate in either 8 bit mode with D/C or in 9 bit mode. This is usually pin configurable. If your CPU doesn't support 9 bit SPI then you will need to modify the display board, use bit banging SPI (not simple), or find another display.

[Tomasz]

Hi,

Thank you guys for prompt response and hints. I will check the olimex example. However, I 'm not sure this will fix the problem fully.

This is not a typical 9bit SPI. The whole byte (0x00 or 0x80) needs to be send prior data/command bytes.

Please see the attached code snippet from their app note.

 

 

[inmarket]

Those routines are typical of routines you would see at the board file level. They describe how to convert a logical operation into a physical one. For example, the logical operation is writePixel, the physical requires the details inside SPI_DataWrite_Pixel.

Your driver will call those routines. Those routines will be in the board file of the driver.

Note: This actually looks like 16 bit SPI with the top bits indicating data/cmd and read/write. You might rearrange the board interface like follows...

write_cmd8(g, c) = SPI_CmdWrite(c)

write_data8(g, d) = SPI_DataWrite(d)

write_data16(g, w) = {

    write_data8(g, (gU8)w)

    write_data8(g, w >> 8 )

}

Read instructions are similar.

If you compare this to other driver board interfaces you will see this is very similar. You then just need to write the driver itself.

Note: By doing this board level extraction the same driver could be used with the display controller in 8080 bus mode simply by changing the implementation of the board routines above.

For the driver, having had a quick look at the data sheet, it is basically a "window" model driver that effectively uses the "MCU write with ROP" controller instruction. When you have that working you can then add an accelerated block fill routine using the controller "rectangle fill" instruction. 

There is another controller that is similar in that it is a window driver and has a accelerated block fill routine. From memory (I am currently away from my computer) it might be the SSD1331 driver or one of the RA drivers.

Hope this helps.