esp-lcd I80 bus is not able to receive. (IDFGH-14546)

[kdschlosser]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

5.2.3

Espressif SoC revision.

ESP32-S3

Operating System used.

Linux

How did you build your project?

Command line with CMake

If you are using Windows, please specify command line type.

None

Development Kit.

Custom

Power Supply used.

External 5V

What is the expected behavior?

I expect to be able to read the registers on the display

What is the actual behavior?

It doesn't do anything. nothing is received at all.

This is the display IC I am using.

https://www.buydisplay.com/download/ic/RA8876.pdf

I need to be able to receive using the I80 bus to make it work.

Steps to reproduce.

Unless you have the display IC to test with outlining the steps is not going to help at all.

Debug Logs.

More Information.

I looked at the I80 code and it appears that the ability to receive might not exist. I am not 100% sure on that. If that is the case why would it have been written without the support to receive data? I can provide a bitbang example of how to do it except it's not for the ESP32 line of MCU's

[suda-morris]

Hi @kdschlosser The backend peripheral of the ESP32-S3 i80 IO driver doesn't have the ability of "receiving".

[kdschlosser]

The backend IO driver you are referring to is it software or hardware?
If it's software and the hardware is capable of receiving then this still falls into line with the bus driver not receiving.

If it's a hardware then that is a bad limitation to have. There are display IC's that do transmit data to the MCU over an I8080 connection. Displays IC's like the RA8876. While I am able to code around not having the ability to receive with that specific display IC it ends up with a cost of having to connect a few additional pins to be able to do it. I mention that specific IC because it does send data back to the MCU. The additional pins really puts the strangle hold on with that specific display IC especially if there is an RGB to MIPI bridge IC that needs to be configured.

Having to reinvent the wheel by needing to design and manufacture a PCB with a different display IC instead of being able to use an off the shelf display with integrated IC will not allow for my project to be completed. The display that I need to use needs to be close to an 8" bar type display. I need to have a decent resolution as well, something around 1280 x 400. My choices are MIPI and I8080 (need to have the speed available). Since the P4 is unobtainium (not for retail sale) that leaves only a single bus type I am able to use which would be I8080.

[suda-morris]

The backend IO driver you are referring to is it software or hardware?

Sorry I didn't clarify it clearly. It's the hardware (the LCD_CAM peripheral) that is not capable of doing LCD receiving (we can only transmit data to the LCD device).

May I know what information that you want to read from the LCD device?

[kdschlosser]

The state of the IC. There are different states that let the MCU know if it is able to transmit more data or if it needs to wait. Things of that nature. There is also the register settings on the display with need to be adjusted by a single byte at a time but the settings are at the bit level and those settings need to be kept so instead of having to store a local copy of the register data it would be better to collect the data from the display IC and update it and then send it back. There is also that gray area of the default values that are listed in the data sheet actually being correct. If I am not able to collect the state from the display I have to connect 2 additional pins. one is a kind of interrupt pin and the other is a wait pin.

EDIT

I didn't realize that I had not pressed the comment button. My bad on that.