Advice on adding a new QSPI panel

[Shadowtrance]

Messing around with the QSPI branch trying to add a new panel / screen config but it seems to be way above my pay grade and I can't figure out where to go from here tbh.

It compiles and "seems" to sort of wake the screen but i get no output. I copied another panel that was a similar setup and eyeballed the hell out of Arduino_GFX to try and figure out what's going on (it works with that library).

I'm just banging my head against a wall atm it seems so thought I'd see if anyone can help get it going.

Screen in question is the JC3248W535EN with the AXS15231B controller.

Here's a mess of things I've put together. https://gist.github.com/Shadowtrance/d69e91671e1b77b7c66624279decc71b

[tobozo]

hi,

The QSPI branch was an attempt to integrate changes from a qspi-dedicated fork but it is based on older versions of LovyanGFX and esp-idf core. This branch is kept as is because the originating fork has been deleted.

arduino-esp32 3.1.x was supposed to get native support for QSPI through the SPI library, but it hasn't happened yet.

Arduino_GFX is currently the best model to follow because it uses esp-idf functions instead of trying to inherit from arduino-esp32 SPI API.

[Shadowtrance]

So qspi is a no go atm with LGFX?
Or is my config just not correct in some way? (highly likely)

Guess I'll have to wait for proper qspi support or figure out how to adapt the project i wanted to use which uses LGFX (TFT ESPI) functions to work which I don't think Arduino GFX has. :(

Thanks for the reply. :)

[tobozo]

your config looks correct, but Bus_QSPI just doesn't init, as you can see here Bus_QSPI calls initQuad():

https://github.com/lovyan03/LovyanGFX/blob/QSPI/src/lgfx/v1/platforms/esp32/Bus_QSPI.cpp#L148

however the bus initialization code block is commented out, waiting for espressif to have SPI.begin() handle QSPI:

https://github.com/lovyan03/LovyanGFX/blob/QSPI/src/lgfx/v1/platforms/esp32/common.cpp#L554-L566

you can try uncommenting those lines as a start, this is where I stopped testing:

https://github.com/lovyan03/LovyanGFX/blob/QSPI/src/lgfx/v1/platforms/esp32/common.cpp#L563-L566

[Shadowtrance]

hmm that didn't seem to make a difference.
I did however get "some" more life out of it after changing some of the init commands after looking at the https://github.com/esp-arduino-libs/ESP32_Display_Panel AXS15231B branch. But what flashes i do see appear to be partially off screen which is kinda weird. Running PDQgraphicstest.

Setting cfg.spi_mode to 3 results in backlight on but no other screen life, cfg.spi_mode 1 and 2 result in the partial life above.

It's fun tinkering with things and making even a tiny bit of progress. haha

[Shadowtrance]

So after some messing around with this and arduino gfx it seems the key to success is the "canvas (framebuffer i guess?)" thing arduino gfx uses.
I disabled the canvas and it acted exactly the same as with lgfx mentioned above. (so just using the qspi bus and panel controller type)
Haven't looked any further yet to see if lgfx has anything similar.
Back to digging around code. :)

[tobozo]

I'm not sure what that canvas/framebuffer has to do with QSPI displays or why/if/when it is required, will RTFM 🤣

LGFX_Sprite class sounds like a good candidate for a canvas but it may be too much for a framebuffer.

Maybe the SpriteBuffer class would be a good fit?

Or maybe a framebuffer=ps_malloc( width*height*bpp ) will be enough as a start.

I'm still waiting for my QSPI devices to be delivered so I can only help with theory, for now 😊

[Shadowtrance]

Yeah I'm sure either tbh. I just know it works lol
And for this particular display/controller it is set up like this in arduino gfx (can also see how it's in done in their PDQ Graphics Test example with the included files.)

Arduino_DataBus *bus = new Arduino_ESP32QSPI(45 /* CS */, 47 /* SCK */, 21 /* D0 */, 48 /* D1 */, 40 /* D2 */, 39 /* D3 */);
Arduino_GFX *g = new Arduino_AXS15231B(bus, GFX_NOT_DEFINED /* RST */, 0 /* rotation */, false /* IPS */, 320 /* width */, 480 /* height */);
#define CANVAS
Arduino_Canvas *gfx = new Arduino_Canvas(320 /* width */, 480 /* height */, g, 0 /* output_x */, 0 /* output_y */, 0 /* rotation */);

Then after that instead of calling tft.whatever like you do with LFGX or TFT_eSPI you call gfx->whatever.... and it does stuff.

[tobozo]

At this stage it may be interesting to know what kind of psram the device is using.

From what I understood so far:

• That QSPI+framebuffer operating mode implies that spiram freq >= bus freq, spiram size >=320*480*4 bytes, and spiram type = quad|octal spi.
• Alternatively, esp32 devices with slower psram (or without psram) would need to use MIPI DSI mode instead

[Shadowtrance]

I think i linked some info regarding this screen in the QPSI / MIPI discussion you made but it's using 8M OPI (octal spi?) psram according to the arduino settings they say to use in the getting started guide.

[tonbor]

This code is still not working at https://gist.github.com/Shadowtrance/d69e91671e1b77b7c66624279decc71b . Did you succeed in making the JC3248W535EN with the AXS15231B work with LovyanGFX? If yes how?

[nikthefix]

@tonbor
I have the JC3248W535EN but have not looked at LovyanGFX for a while.
I'll try them out together asap.
In the meantime, if you have any working esp-idf examples for this board then you might compare the qspi settings and panel initialization sequences since Lovyan derives it's configuration from IDF and not via Arduino ESP32 Core so the settings should transfer.

Additionally: If your getting a successful build but with a blank screen at runtime then see if it's blank but with the backlight shining. If the backlight is not illuminating at all then I suspect the problem is due to breaking changes in the Arduino Core which saw the syntax for LEDC (pwm control of backlight leds in this case) change quite recently. The fix is easy but check the migration documents for ESP32_Arduino and look for changes to LEDC. I seem to remember that at one point I had to explicitly set the BL pin as output in the sketch in order to get it (the PWM) to fire up.

BTW, I wouldn't say that Lovyan is a far better library than Arduino_GFX.
They are different in ways that users may see as pro or cons:

In my opinion, Lovyan and M5GFX are tied close to IDF which is efficient and arguably desirable.

Arduino_GFX is more abstracted but the author keeps pace better than all the others with regular updates to accommodate new boards, displays and Core updates. Configuration is done at the sketch level which may be important for some.
It's also a more C++ style lib if that's what you prefer.

M5GFX is also fast to update but functionality is obfuscated and buried quite deep in 'unified libraries' making the code hard to dissect - many #ifdefs

TFT_eSPI is the OG and reigns supreme for many. Lack of support for QSPI/MIPI doesn't matter if you supply your own display driver (see my github for examples).

LVGL is amazing but you have to do work to interface it to your hardware. Plenty of examples for most maker boards.

But they're all GREAT!

[tonbor]

@tonbor I have the JC3248W535EN but have not looked at LovyanGFX for a while. I'll try them out together asap. In the meantime, if you have any working esp-idf examples for this board then you might compare the qspi settings and panel initialization sequences since Lovyan derives it's configuration from IDF and not via Arduino ESP32 Core so the settings should transfer.

much obliged

[tonbor]

jc.txt
This can perhabs help you to get the bus and panel right for lovyangfx library
https://github.com/NorthernMan54/JC3248W535EN/blob/main/src/esp_lcd_axs15231b.c
ESP_LOGI(TAG, "Initialize QSPI bus");
const spi_bus_config_t buscfg = AXS15231B_PANEL_BUS_QSPI_CONFIG(EXAMPLE_PIN_NUM_LCD_PCLK,
EXAMPLE_PIN_NUM_LCD_DATA0,
EXAMPLE_PIN_NUM_LCD_DATA1,
EXAMPLE_PIN_NUM_LCD_DATA2,
EXAMPLE_PIN_NUM_LCD_DATA3,
EXAMPLE_LCD_H_RES * 80 * sizeof(uint16_t));
ESP_ERROR_CHECK(spi_bus_initialize(EXAMPLE_LCD_HOST, &buscfg, SPI_DMA_CH_AUTO));

ESP_LOGI(TAG, "Install panel IO");
esp_lcd_panel_io_handle_t io_handle = NULL;
const esp_lcd_panel_io_spi_config_t io_config = AXS15231B_PANEL_IO_QSPI_CONFIG(EXAMPLE_PIN_NUM_LCD_CS, callback, &callback_data);
ESP_ERROR_CHECK(esp_lcd_new_panel_io_spi((esp_lcd_spi_bus_handle_t)EXAMPLE_LCD_HOST, &io_config, &io_handle));

/**

• Uncomment these line if use custom initialization commands.

• The array should be declared as static const and positioned outside the function.
  */
  // static const axs15231b_lcd_init_cmd_t lcd_init_cmds[] = {
  // // {cmd, { data }, data_size, delay_ms}
  // {0xFF, (uint8_t []){0x20, 0x10, 0x10}, 3, 0},
  // {0x0C, (uint8_t []){0x11}, 1, 0},
  // {0x10, (uint8_t []){0x02}, 1, 0},
  // {0x11, (uint8_t []){0x11}, 1, 0},
  // ...
  // };

  ESP_LOGI(TAG, "Install AXS15231B panel driver");
  esp_lcd_panel_handle_t panel_handle = NULL;
  const axs15231b_vendor_config_t vendor_config = {
  // .init_cmds = lcd_init_cmds, // Uncomment these line if use custom initialization commands
  // .init_cmds_size = sizeof(lcd_init_cmds) / sizeof(axs15231b_lcd_init_cmd_t),
  .flags = {
  .use_qspi_interface = 1,
  },
  };
  const esp_lcd_panel_dev_config_t panel_config = {
  .reset_gpio_num = EXAMPLE_PIN_NUM_LCD_RST,
  .rgb_ele_order = LCD_RGB_ELEMENT_ORDER_RGB, // Implemented by LCD command 36h
  .bits_per_pixel = 16, // Implemented by LCD command 3Ah (16/18)
  .vendor_config = &vendor_config,
  };
  ESP_ERROR_CHECK(esp_lcd_new_panel_axs15231b(io_handle, &panel_config, &panel_handle));
  esp_lcd_panel_reset(panel_handle);
  esp_lcd_panel_init(panel_handle);
  esp_lcd_panel_disp_on_off(panel_handle, true);

[tonbor]

@tonbor I have the JC3248W535EN but have not looked at LovyanGFX for a while. I'll try them out together asap. In the meantime, if you have any working esp-idf examples for this board then you might compare the qspi settings and panel initialization sequences since Lovyan derives it's configuration from IDF and not via Arduino ESP32 Core so the settings should transfer.

Additionally: If your getting a successful build but with a blank screen at runtime then see if it's blank but with the backlight shining. If the backlight is not illuminating at all then I suspect the problem is due to breaking changes in the Arduino Core which saw the syntax for LEDC (pwm control of backlight leds in this case) change quite recently. The fix is easy but check the migration documents for ESP32_Arduino and look for changes to LEDC. I seem to remember that at one point I had to explicitly set the BL pin as output in the sketch in order to get it (the PWM) to fire up.

BTW, I wouldn't say that Lovyan is a far better library than Arduino_GFX. They are different in ways that users may see as pro or cons:

In my opinion, Lovyan and M5GFX are tied close to IDF which is efficient and arguably desirable.

Arduino_GFX is more abstracted but the author keeps pace better than all the others with regular updates to accommodate new boards, displays and Core updates. Configuration is done at the sketch level which may be important for some. It's also a more C++ style lib if that's what you prefer.

M5GFX is also fast to update but functionality is obfuscated and buried quite deep in 'unified libraries' making the code hard to dissect - many #ifdefs

TFT_eSPI is the OG and reigns supreme for many. Lack of support for QSPI/MIPI doesn't matter if you supply your own display driver (see my github for examples).

LVGL is amazing but you have to do work to interface it to your hardware. Plenty of examples for most maker boards.

But they're all GREAT!

Any progress?

[nikthefix]

@tonbor
I've been snowed under with other work recently but did dig out what I thought was the JC3248W535EN only to find that it was the WT32-SC01-Plus (8080 parallel so of no use here).

However I do have the Lilygo T-Display-S3-Long which uses the same display and touch driver as JC3248W535EN.
I'll try to come up with something but I'm flying blind without the actual hardware so bear with me.

At the end of the day, given that the master LovyanGFX does not explicitly support QSPI displays, the solution is to create a full screen sprite in Lovyan and use it as your 'canvas' which you then push to your QSPI display driver.

I did exactly this for TFT_eSPI and the Long - see my github.
I'll try to get back to you with something useful asap.