correct firmware naming

[proddy]

As Michael reported in #1930

The S32 gateways (without S3) have 16M flash without PSRAM, It can't handle the 16M file. The 16M file is compiled with -DEMSESP_DEFAULT_BOARD_PROFILE="E32V2 and defaults on factory reset to the wrong board-pins when flashed to S32.

Originally posted by @MichaelDvP in https://github.com/emsesp/EMS-ESP32/issues/1930#issuecomment-2282749387

Today it looks like:

[proddy]

I suggest we change the platformio env names, the GitHub actions and the Web firmware download code to build and check for these variants:

EMS-ESP-<version>-<chip type>-<flash mem>.bin

chip type is S, S3, perhaps C3 flash mem is 4, 16, 32

do we need to explicitly check for PSRAM too?

@MichaelDvP I am missing anything?

[MichaelDvP]

I think we should check the common chips and the BBQKees gateways, form old to new:

1. gateway premium - ETH-live-Mini, ESP32, 4M
2. gateway premium - LiligoS3: ESP32S3, 16M, PSRAM
3. gateway premium Lolin Mini C3 or Mini S2
4. gateway S32 - nodeMCU ESP32, 4M
5. gateway E32 - ESP32, 4M
6. gateway S32 - soldered chip, ESP32, 16M
7. gateway S3 - ESP32S3, 16M, PSRAM
8. gateway E32V2 - ESP32, 16M, PSRAM
9. ems-interface with common modules, nodeMCU, ETH-Live, Liligo, etc.

• ESP32S3 firmware works with all S3 cips (2. and 7.), defaults to board gateway S3, on the Liligo chip LED is not working. need configuring, but boots upwith AP.
• ESP32-16M frmware only fits to the E32V2, bootloop due to low ram on the ESP32 without PSRAM (tested with the gateway 6.)
• ESP32 firmware is updateable without issue to v3.6.5 and works for all ESP32 versions.

For C3 and S2 we don't have prcompiled firmare. Also for 32M chips, there was only a S3-32M with OPI-flash that needs a special compile env.

[proddy]

Okay. We still need a naming convention and then we can code it. The chip types are only ESP and ESP-S3 for now. Are you suggesting we don't keep it ESP generic but use the BBQKees gateway naming? I'm fine with either approach.

[MichaelDvP]

I think it's all ok, but use in uploadDownload.tsx:

  const getPlatform = () => {
    if (data.flash_chip_size >= 16384 && data.esp_platform === 'ESP32' && data.psram) {
      return data.esp_platform + '-16M';
    }
    return data.esp_platform;
  };

to match only the E32V2 for the 16M update. (or user modules with ESP32 and at least 16M and PSRAM)

[bbqkees]

1, 2 and 3 are the ESP8266 Gateways that were user-upgraded with a new module so those would all more or less fall under 9.

4. The earliest S32 V1.0 indeed has a NodeMCU module with 4MB of Flash.
5. The later S32 V2.0 had a new internal design with a soldered ESP32 module and from then onwards they always had 16MB of flash.
6. The E32 V1.0 to V1.5 had 4MB flash.

When it became apparent that EMS-ESP could benefit from more RAM, i started working on new models with PSRAM. Now we have the currently available models the S3 and the E32 V2.

7. The S3 has the ESP32-S3 with 8MB PSRAM and 16MB Flash.
8. The E32 V2 has the ESP32 with 8MB PSRAM and 16MB Flash.

Because Espressif removed the hardware Ethernet support from the ESP32-S3, I opted for the ESP32 with PSRAM for the ESP32 V2 so Ethernet would remain rock solid. As the S3 Gateway only has Wi-Fi, I could use the ESP32-S3 on that one.

https://bbqkees-electronics.nl/wiki/gateway/hardware-details.html

[proddy]

Format now is:

EMS-ESP-<version>-<chip type>-<flash mem>[+].bin

chip type is as defined in esp_platform from pio. ESP32, ESP32S3, ESP32C3 etc. All uppercase. flash mem is either 4MB or 16MB. + is added at the end if there is PSRAM

example:

[proddy]

There is one catch with this change. Because of the filename change, the links from the Web download/upload page will be wrong. For the dev version, you will need to manually pull the binary from the GH Release page. And for those on Stable the same. When we have 3.7.0 into Stable everything will be aligned again.