TTGO Lora v2

[wurst44]

Would this or the M5Stack-SD-Updater work with the TTGO Lora v2?

Thank you

[tobozo]

Hello Peter and thanks for your feedback,

This is the ESP32-Chimera-Core project and you're asking about M5Stack-SD-Updater so I'll assume your question is about Display, Buttons and SD integration.

• ESP32-Chimera-Core can detect some TFT display models and start them automatically, and LGFX (the underlying display driver) can eventually drive OLED displays, but this has never been tested.
• ESP32-Chimera-Core does not provide Buttons support for unknown profiles (there is no standard pinout for that). If you implement your own buttons, you'll need to reinit BtnA/BtnB/BthC using some contructor voodoo in setup() e.g. new (&M5.BtnA) Button(39, true, 10); for a button on pin 39 with 10ms debounce
• ESP32-Chimera-Core does not init the SD/SD_MMC when the board is unknown, so you'll have to start it manually from the setup().
• M5Stack-SD-Updater lobby screen is calibrated for 320x240 displays. If you need a lobby screen, you'll have to implement your own callback triggers and UI.
• M5Stack-SD-Updater has a headless mode if you don't want to use the lobby screen or even buttons (e.g. can be triggered by sensor, serial or network).

So all in all, ESP32-Chimera-Core doesn't support much of TTGO-Lora32-V2 and you probably don't need it.

M5Stack-SD-Updater's headless mode is probably your best bet, I'll push an update soon to fix the examples.

Here's a preview of the fixed version for the headless mode:

#define SDU_APP_NAME "Headless Example" // my app name
#define SDU_APP_PATH "/Headless_Example.bin"  // my binary file will be named after that on the SD Card
#define SDU_HEADLESS     // don't load gfx clutter (but implement my own action trigger)
#define TFCARD_CS_PIN 4  // note: SD_MMC.h doesn't need that, only SD.h does
#include <SD.h>
#include <M5StackUpdater.h>


static int myActionTrigger( char* labelLoad,  char* labelSkip, char* labelSave, unsigned long waitdelay )
{
  int64_t msec = millis();
  do {
    if( Serial.available() ) {
      String out = Serial.readStringUntil('\n');
      if(      out == "update" )  return  1; // load "/menu.bin"
      else if( out == "rollback") return  0; // rollback to other OTA partition
      else if( out == "skip" )    return -1; // do nothing
      else if( out == "save" ) return 2;
      else Serial.printf("Ignored command: %s\n", out.c_str() );
    }
  } while( msec > int64_t( millis() ) - int64_t( waitdelay ) );
  return -1;
}


void setup()
{
  Serial.begin( 115200 );
  Serial.println("Welcome to the SD-Updater Headless example!");
  Serial.println("Now waiting 30 seconds for user input in Serial console...");

  SDUCfg.setWaitForActionCb( myActionTrigger );

  checkSDUpdater(
    SD,           // filesystem (default=SD)
    MENU_BIN,     // path to binary (default=/menu.bin, empty string=rollback only)
    30000,        // wait delay in milliseconds (default=0, e,g, 30000 will be forced to 30 seconds upon ESP.restart() )
    TFCARD_CS_PIN // (usually default=4 but your mileage may vary)
  );

  Serial.println("Starting application");


}

void loop()
{


}

[wurst44]

Thanks for your detailed answer. Headless sounds great. I guess buttons pins are defined code, so there should be no problem. Mainly with the SD card I will need some testing to fulfill the purpose of SD-Updating 😉 I will play with it. There is also a nice menu lib for the SSD1306 mini tft that is on all of these Lora devices that are on the market like Heltec, Lilygo. And why not with a plain esp32 and SD reader only.

I went to the SD updater repo to understand how my subprojects are integrated and saw that project source folders are linked? Is it not using binaries? Sry for the stupid question

[tobozo]

The github submodules are only there as application examples compatible with the M5Stack version of the SD-Menu.

Those submodules are kept for history reason, also because some authors participated in the elaboration of the library by testing it with their own app.

There used to be a zip with precompiled binaries, it was used to pre-fill the SD when testing the SD-Menu, but the building process was relying on the free version of travis ci which is now limited, and it created a compatibility problems between different flavours of M5Stack device, depending on the core version.

Those applications aren't bundled with the release tarball anymore, there are too many combinations of partition scheme + device to take into account.

Moreover, building apps is outside the scope of the M5Stack-SD-Updater repository so I'm thinking about moving the SD-Menu and other tools to a separate project.

[tobozo]

Support for TTGO-T-Display was just added to the auto-detection list on LovyanGFX develop branch.

lovyan03/LovyanGFX#170 (comment)

This device display model looks very similar to the one on TTGO-Lora-V2, so Chimera-Core will eventually inherit that support.

You can preview the autodetection support by updating your local LovyanGFX version with the develop branch.

However I still can't profile those in the SD-Updater, since both TTGO devices come without SD Card, the filesystem assignation still needs to be done manually, and the default UI is still based on 320x240 display.

[wurst44]

Thank you and @lovyan03, I am eager to test it soon. My device as most (all) Lilygo TTGO Lora should have SD card support as shown in my pictures/board schematics on top. Regards

[tobozo]

I'm creating a new profile in the Chimera-Core to handle this device but the choice in boards.txt is currently limited to TTGO_LoRa32_V1 and TTGO_LoRa32_v21new, none of which use the same pinout, so there can't be a profile detection from the boards menu as it is.

I've ordered a TTGO LoRa32 V2.0 so I'll soon be able to do more than theorize.

There seems to be a support for that board variant in the espressif32 sdk, it probably failed to be properly inserted to the boards.txt file in the latest release and it won't be there any time soon.

For the meantime I'm inserting a fictious ARDUINO_TTGO_LoRa32_V2 board name to my boards.local.txt file, and I'll be using it until espressif adresses the issue.

Can you confirm this starts the SD card on your device?

  SPI.begin(14, 2, 15);
  if(!SD.begin(13)){
      Serial.println("Card Mount Failed");
      return;
  }

That's not the fastest config it can use though, but if it works, the "formula" to get the SD-Updater to work headless is as follows:

#define TFCARD_CS_PIN 13
#define SDU_HEADLESS
#include <M5StackUpdater.h>

void setup()
{
  Serial.begin(115200);
  SPI.begin(14, 2, 15);
  checkSDUpdater( SD, MENU_BIN, 5000, TFCARD_CS_PIN );
}

With such a setup it will wait for serial input for 5 seconds and start the app,

Now I'm not sure it's worth waiting for OLED support

[tobozo]

hey ^^ I've received my TTGO-LoRa32-V2 yesterday and successfully had it running on LGFX with the following init code:

#define LGFX_USE_V1
#include <LovyanGFX.hpp>

class LGFXOled : public lgfx::LGFX_Device
{
  lgfx::Panel_SSD1306 _panel_instance;
  lgfx::Bus_I2C       _bus_instance;

  public:

  LGFXOled(void)
  {
    {
      auto cfg = _bus_instance.config();
      cfg.pin_sda = OLED_SDA;
      cfg.pin_scl = OLED_SCL;
      cfg.i2c_addr = 0x3C;
      _bus_instance.config(cfg);
      _panel_instance.setBus(&_bus_instance);
    }
    {
      auto cfg = _panel_instance.config();
      cfg.memory_width  = cfg.panel_width  = 128;
      cfg.memory_height = cfg.panel_height = 64;
      _panel_instance.config(cfg);
    }
    setPanel(&_panel_instance);
  }
};

static LGFXOled oled;

void setup()
{
  Serial.begin(115200);
  oled.print("BLAH");
}

void loop 
{
}

I can confirm it will end up in Chimera-Core as soon as it's added to the LGFX official autodetect list.

reading the SD Card however seems a bit clunky on this device, I had to insert the SD Card exactly 300ms avec resetting the ESP32 to have it correctly detected using the following code:

  SPI.begin( 14, 2, 15 );
  if( !SD.begin( 13 ) ) {
    Serial.println("SD Error");
  }

and once the SD Card is inserted, any further attempt to flash the ESP fails until the SD Card is removed.

From a few posts I've read about the PaxCounter this seems to be a known problem that can be solved with a small capacitor, so I will proceed with the SDUpdater tests first, and then contribute to espressif32 repository with the modified boards.txt file.

[tobozo]

TTGO Lora32 (v2 and two other versions) boards got merged so the next espressif32-arduino release will support it.

[tobozo]

new release was published, the TTGO LoRa32 boards should now be properly listed

https://github.com/espressif/arduino-esp32/releases/tag/2.0.2