Page 1 of 1

Status of esp_lcd component

Posted: Sun Sep 29, 2024 8:34 pm
by crosser
I was trying to port the driver for RM67162 OLED panel controller that comes with recent lilygo board from adhoc arduino version that lilygo provides to "proper" component that could work with idf's `esp_lcd`, to leverage queued transactions.

Existing and working driver runs transactions using command 0x02 (8 bit) (or 0x32 for pixel data write) and 24 bit "address" that is constructed from a traditional LCD panel command left-shifted by 8 bits, for example `cmd=0x02, addr=0x11<<8` for "sleep out" command. When the command requires parameters, they are passed via `tx_buffer` / `length` fields of the spi transaction structure. To clarify, I modified the code to work without arduino component, under pure idf. It works.

But looking at the code in `components/esp_lcd`, there is no mention of `cmd` and `addr` fields. Command and parameter data seem to be transmitted entirely via the `tx_buffer` pointer, in separate transactions.

As the board does not use DC pin, I can imagine that things _may_ work if you put command and address in the data buffer. So I have two questions:
  • Is `esp_lcd` component "recommended" / "supported"?
  • If it is, what are the rules to convert cmd+addr based transaction to an equivalent buffer-only transaction?
Bootnote: original lilygo driver code taken from their examples here https://github.com/Xinyuan-LilyGO/T-Dis ... n/examples

Re: Status of esp_lcd component

Posted: Mon Sep 30, 2024 9:46 pm
by crosser
I figured it out. Module uses DC-less 16bit transfer mode; and the "command code" which is the same as the "address" is 16bit wide. So without DC pin the "command" expands to 32 bits (four bytes: control byte, hi byte of address, control byte, lo byte of the address).
Pattern modelled after the existing code does not exactly match the datasheet, but hey, I have pretty colours!

So this is what I had to do:

Code: Select all

                        .lcd_cmd_bits = 32,
                        .lcd_param_bits = 8,
and pass 32bit integer as the command to the transactions, patterned as `0x0200xx00`, where xx is the usual LCD command code.

Re: Status of esp_lcd component

Posted: Wed Oct 02, 2024 8:09 pm
by crosser
And just in case somebody needs it, I've put a working example, including the driver, here: https://github.com/crosser/lvgl_esp_lcd