Suggestion: M5Stack Core2 Compat about m5stack-sd-updater

[tobozo]

The buttons are already emulated by the latest M5Core.h code (pull it from the master, it's not yet in a release), only you can't have the "turn on the M5 while pressing the display" so you'll have to use the third argument (waitdelay) of checkSDUpdater() to get this screen visible long enough to receive the touch signal.

void setup() {
  M5.begin();
  checkSDUpdater( SD, MENU_BIN, 2000 ); // will wait 2 seconds for a push/touch on BtnA
}

Otherwise there's a UI work in progress but not yet enabled with M5Core2.h, only with ESP32-Chimera-Core.

[vkichline]

Thanks! That's usable, but sub-optimal; I really liked the non-intrusive method that was available before, for when the general case is "I just want to start up normally" and the exceptional case is "I want to run the menu program."
I suppose I could just implement my own test in setup(), and then call updateFromFS() if it's positive.

[tobozo]

Using a NVS entry that will affect the behaviour of the SD-Updater on next reboot is very clever, thanks!

I'll try to use rtc_get_reset_reason(0) but I have no idea which one of those is the double reset :

void print_reset_reason(RESET_REASON reason)
{
  switch ( reason)
  {
    case 1 : Serial.println ("POWERON_RESET");break;          /**<1, Vbat power on reset*/
    case 3 : Serial.println ("SW_RESET");break;               /**<3, Software reset digital core*/
    case 4 : Serial.println ("OWDT_RESET");break;             /**<4, Legacy watch dog reset digital core*/
    case 5 : Serial.println ("DEEPSLEEP_RESET");break;        /**<5, Deep Sleep reset digital core*/
    case 6 : Serial.println ("SDIO_RESET");break;             /**<6, Reset by SLC module, reset digital core*/
    case 7 : Serial.println ("TG0WDT_SYS_RESET");break;       /**<7, Timer Group0 Watch dog reset digital core*/
    case 8 : Serial.println ("TG1WDT_SYS_RESET");break;       /**<8, Timer Group1 Watch dog reset digital core*/
    case 9 : Serial.println ("RTCWDT_SYS_RESET");break;       /**<9, RTC Watch dog Reset digital core*/
    case 10 : Serial.println ("INTRUSION_RESET");break;       /**<10, Instrusion tested to reset CPU*/
    case 11 : Serial.println ("TGWDT_CPU_RESET");break;       /**<11, Time Group reset CPU*/
    case 12 : Serial.println ("SW_CPU_RESET");break;          /**<12, Software reset CPU*/
    case 13 : Serial.println ("RTCWDT_CPU_RESET");break;      /**<13, RTC Watch dog Reset CPU*/
    case 14 : Serial.println ("EXT_CPU_RESET");break;         /**<14, for APP CPU, reseted by PRO CPU*/
    case 15 : Serial.println ("RTCWDT_BROWN_OUT_RESET");break;/**<15, Reset when the vdd voltage is not stable*/
    case 16 : Serial.println ("RTCWDT_RTC_RESET");break;      /**<16, RTC Watch dog reset digital core and rtc module*/
    default : Serial.println ("NO_MEAN");
  }
}

RTC and IMU logic should probably be handled by the sketch though.

[tobozo]

Are you still on this ? I've just pushed some code on the "driverless" version where I've implemented some of your suggestions.

Current behaviour with Touch/SD stays non invasive, no SD-Updater UI is visible both on PushButton and Touch versions, however, issueing a ESP.restart() will make it visible on next reboot.

This behaviour can also be bypassed to make the SD-Updater UI visible at all times by forcing a timeout

    checkSDUpdater( SD, MENU_BIN, 2000 ); // will wait 2 seconds

The SD Updater class now supports three types of assertions to trigger de sd-loading :

• Serial input (headless support, no HID)
• GPIO button push (M5Stack classic, Odroid-Go)
• Touch button press (M5Core2, TWatch, ESPMarauder)

Moreover, you can overload the class with your own push/touch/sensor/whatever assertion from outside the class.

This should ease the testing of the IMU/RTC options you were suggesting earlier.

Please let me know if you're motivated by this and I'll document it.

[vkichline]

Thanks! I had implemented a test for reset-while-upside-down and was pretty happy with it, but I will be glad to download and test this out, it may be better. Schedule looks full today but I will get to it by tomorrow.
I'm interested in:

Moreover, you can overload the class with your own push/touch/sensor/whatever assertion from outside the class.

I had considered suggesting that, but I tend to go on and on.

[vkichline]

It looks like it prefers ChimeraCore for Core2; I changed the includes, but encountered:
downloader.h:40:25: fatal error: ESP32-targz.h: No such file or directory
Also, I see the TouchButtons must be Chimera-style; the current (w/o a new release number) M5Core2.h has different TouchButtons by RopG.
But just because I've never used ChimeraCore doesn't mean I can't; I'd still love to try this out.
I'll have to figure out what's necessary...

[tobozo]

oops it's probably looking for this library, I'm also preparing a more straightforward app downloader ^^

if not using the Chimera-Core, this is the M5Core2 fork you should be using : https://github.com/ropg/M5Core2/tree/visual

hopefully it'll land soon on the official repo

[tobozo]

Found this library as a valid example of double reset detection but I think I'll keep the NVS option for the meantime.

Followup on Rop's library : still showing some issues with detection at boot, but looks promising for code unification.

[tobozo]

bump

M5Core2 support enabled in the latest release, however it comes with constraints:

• User must implement "touch" logic by using early callback setters
• If no user implementation is done, ESP32-Chimera-Core is required
• Shows a lobby screen on every boot

Closing this as solved, feel free to reopen or add some followup if you feel something is missing or broken.