Add ST7796S support (IDFGH-7026)

[ya-mouse]

Add support for ST7796S LCD panel.

Tested on WT32-SC01 board.

[CLAassistant]

All committers have signed the CLA.

[Alvin1Zhang]

Thanks for your contribution.

[suda-morris]

Thank you @ya-mouse for contributing your code to esp_lcd. The code itself is really neat and it follows the interface very well!
However, after comparing the st7796 driver with the existing st7789, I didn't see much difference, except the name.

If I understand correctly, st7796 shares the same register layout with st7789 but some default register value needs to be changed. For example, st7789 needs an inversion but st7796 doesn't. This doesn't have to be addressed in the driver, but can also be handled from userspace, by calling esp_lcd_panel_invert_color.

So according to the DRY principle, I would suggest to use the st7789 driver to turns on your st7796 LCD. How do you think?

[ya-mouse]

@suda-morris good point, originally I was taking the driver from here. The difference with st7789 isn't big, mostly, some init registers. In the esp_lcd drivers everything left with default values (no gamma, no vcom settings and so on). When testing the LCD panel I do calling esp_lcd_panel_invert_color with false value to get normal colors.

Only one artifact that I see during LCD initialization (cold start) is that LCD shows the content of the it's RAM (noisy screen). I suppose the only way is to fillup the screen with initial image and then turn display on (LCD_CMD_DISPON). I didn't find in datasheet something like to initialize the internal memory with zeroes. Neither SW or HW reset affects the memory state (as per datasheet).

[ya-mouse]

A little offtop. I have several EPD screens, their driver supports so-called "9bit SPI". It allows to use one address bit in transaction to reflect D/C pin instead of flipping D/C wire. What will be the better approach to incorporate such change to SPI transactions in esp_lcd?

[suda-morris]

@ya-mouse We've taken that into consideration as well. Yes, we can encode the D/C into either address phase or command phase. The esp_lcd driver provided a configuration called dc_as_cmd_phase just in esp_lcd_panel_io_spi_config_t.

See #8644 (comment)

[ya-mouse]

Oh, that's cool. I was looking for address bits. One more question. The commands are processed in polling mode. The colors transferred by DMA. There is a pool of transactions for DMA. As I understand, before each command we're waiting for DMA transactions' completion. If we use D/C as a cmd phase, wouldn't it better to queue such cmd as DMA transaction even if it's small? For example, if the app do a number of small partial screen updates, there are a number of commands (selecting update window) following with a small chunk of data. If we do all with DMA transactions with a deep enough pool, will we benefit from DMA-only operations (cmd and color)?

[suda-morris]

@ya-mouse A good question. Based on either feedback from our community or from our real test, for a small transaction, polling mode is more efficient than using interrupt+queue. But that test is not based on such 9bit LCD IIRC.

[suda-morris]

FYI, Based on our internal test of this dc_as_cmd_phase flag, it turns out that our SPI hardware can't do the "9bit SPI" transaction very well. We still missed some hardware features in order to drive such a special LCD in a way more elegant. We plan to remove/deprecate that flag. And reenable it when the hardware feature is available. Thanks for your feedback.