M5Stack Core2

[joshka]

I'm cutting this issue to attempt to get some feedback on how this works with the M5Stack Core2 (and to highlight a few differences / give some real world thoughs that could help the future refactoring efforts in #1 and #44.

I have an M5Stack Core2, which is fairly similar to the M5Stack Basic, however a few of the GPIOs change, and some move to being on the attached AXP192 power chip (driven over I2C). Details on pins at https://docs.m5stack.com/en/core/core2

Differences:

Function	M5Stack	M5Stack Core2
MISO	GPIO 19	GPIO 38
MOSI	GPIO 23	GPIO 23
CLK	GPIO 18	GPIO 18
CS	GPIO 14	GPIO 5
CS	GPIO 27	GPIO 15
RST	GPIO 33	AXP IO4
BL	GPIO 32	AXP DC3

The AXP192 is accessed via I2C (an example of this is found in https://github.com/m5stack/Core2-for-AWS-IoT-EduKit/blob/master/Blinky-Hello-World/components/core2forAWS/tft/ili9341.c#L89-L93 and the drivers for this are in https://github.com/m5stack/Core2-for-AWS-IoT-EduKit/tree/master/Blinky-Hello-World/components/core2forAWS/axp192)

So the process of initializing this setup includes doing non-GPIO activities to reset the display. My guess for doing this properly right now is to define some more M5Stack Core2 defines and have a couple of #ifdefed methods to slap the I2C bus for the reset and backlight changes. Alternatively, I could add some callbacks for these parts.

So I guess this adds a specific example of why the transport needs to be detached from both the display code (here SPI based) as well as the backlight code (I2C based), but also highlights that there's a possible higher layer code that connects these in a pre-configured sense (e.g. perhaps providing m5stack_basic_display_init() / m5stack_core2_display_init() etc.)

Hoping this helps @zladay in working out the hal approach.

Also of note, the M5Stack actually uses a IL9342C not a IL9341 - the differences as far as I can tell are the orientation (320x240 rather than 240x320), the backlight is controlled by PWM rather than just on/off, there are 4 gamma options rather than just 1, and a few different commands. Additionally, it has a touch screen (FT6336U based).

[sieren]

If it's of any help, many of these changes (incl. a nasty hack for the APX/I2C issue) are demonstrated in this repo: https://github.com/usedbytes/m5core2-basic-idf and in a fork from here: https://github.com/usedbytes/lvgl_esp32_drivers/commits/98b177a2ed38971f2ba1d6d262d9f9a28146e246

[joshka]

If it's of any help

Neat - thanks for those links :)

[tore-espressif]

Hello @joshka ,

thanks for those points.

I agree that support for soft-reset should be added (currently it is supported only in ST7789 driver) for HW usecases that don't connect RST pin of the display to the MCU. See ILI9341 datasheet chapter 8.2.2.. Is that what you had in mind?

If someone wants to reset the display via AXP192, then I'd say that that is HW specific and it shouldn't be handled in lvgl_esp32_drivers.

The same applies to any M5Stack specific functions. There are some convenience functions that can help first-time users with setting-up their boards, but it is meant to be an example rather than full-blown support of specific boards.

Also of note, the M5Stack actually uses a IL9342C not a IL9341

yep, older version of M5Stack used ILI9341, and it wasn't updated :(

I hope that @C47D can share his ideas too.

[C47D]

Hi all,

I was doing a software reset as a fallback in here:

void ili9341_reset(lv_disp_drv_t *drv)
{
    driver_generic_t *driver = (driver_generic_t *) drv->user_data;
    
	/* Reset the display */
    if (driver->hw_reset) {
        driver->hw_reset(drv);
    } else {
        /* Software reset when no hardware reset is available */
        ili9341_send_cmd(drv, ILI9341_CMD_SWRESET);
        driver->delay_ms(drv, 5);
    }
}

That driver have another set of features I was playing with to improve the driver MCU abstraction

[joshka]

I agree that support for soft-reset should be added (currently it is supported only in ST7789 driver) for HW usecases that don't connect RST pin of the display to the MCU. See ILI9341 datasheet chapter 8.2.2.. Is that what you had in mind?

If someone wants to reset the display via AXP192, then I'd say that that is HW specific and it shouldn't be handled in lvgl_esp32_drivers.

My idea is closer to the code written by @C47D, a callback that can be passed in that performs the hw reset, which is called when the reset needs to happen.

[C47D]

@joshka Just checked the hax on the @usedbytes repo, I think it would be better to add support for the M5Core2 kit instead of changing the display orientation array. What do you think?