-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ST7796S support (IDFGH-7026) #8644
Conversation
Thanks for your contribution. |
Thank you @ya-mouse for contributing your code to 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 So according to the DRY principle, I would suggest to use the st7789 driver to turns on your st7796 LCD. How do you think? |
@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 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). |
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? |
@ya-mouse See #8644 (comment) |
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)? |
@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. |
FYI, Based on our internal test of this |
Add support for ST7796S LCD panel.
Tested on WT32-SC01 board.