esp-iot-solution: Unable to use I2S LCD mode with 8-bit parallel

I have ported over an ILI9488 display with an init sequence that’s known to work on other libraries. However I’m noticing the code expects 16 bit commands/registers, and there are no provisions on the code to check for 8 bit data paths for registers. In fact it seems that the 8 bit defines are just plain wrong for the combination of displays with 8 bit commands and 8 bit bus (https://github.com/espressif/esp-iot-solution/blob/db36832d90b0077bc7fa5a455b789497f8a12911/components/i2s_devices/lcd_common/i2s_lcd_com.c#L36 is pretty telling in this regard).

When connected via a 16 bit bus the top byte/8 lines are ignored, but as far as I can tell on 8 bits bus the ILI commands are seemingly being cancelled by NOPs when the bytes are swapped (high byte is 0x0). I unfortunately can’t follow up on this suspicion right now as I don’t have a logic analyser handy. I do know that the connections are right and I do know that bit banging the GPIOs as a bus works. I suspect there could be something weird with the WS clock but first I’d like to make sure that my reading of i2s_lcd_com makes any sense…

For kicks, I also attempted to port over ILI9341 as 8-bit parallel I2S; everything is royally garbled there but I can see some thin strips with parts of what the original image is supposed to be. So I’m still hoping it’s just misconfigured somehow…

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 26 (8 by maintainers)

Most upvoted comments

@classic-gentleman have you managed to drive a ILI9488 display? mind sharing the diff? thanks

Answering myself:

  1. sprite’s settings are indeed correct for data index 0 and device 1.
  2. It seems to be possible to switch settings between transfers. So it’s indeed feasible to get better data density depending on the transfer length.
  3. Jury’s still out on this one…