Explore minimized build for ESP8266 in WipperSnapper v2.0

[brentru]

WipperSnapper v2.0 (and latest 1.0) blows past ESP8266's available flash.

We should explore creating a minimized build for this platform:

• Remove TLS/SSL (which we currently do - check this)
• Remove "sd card logging mode"/offline mode (and file system abstractions)
  • spi, filesystem overhead, and sd card lib (esp bc of the buffer for arduinojson) might be where we find space savings for ESP8266..
• Remove I2C output support
• Remove display support
• Remove GPS support

[brentru]

Check build size metrics (via pioarduino)
Check largest symbols

[tyeth]

I was playing in a few branches, including altering the MMU option from in boards.txt / ci-arduino#ci-wippersnapper-something8266, and in platformio.ini via build flags (I set the mmu flag and a pio specific equivalent flag to get the 48k ram 16k cache, also trying the 2nd heap option).

The issue was it never didn't build, but it wouldn't output anything over serial, presumably crashing at wipper initialisation before serial.
Turning on a debug build, I saw the esp-core sdk version boot message then not much else just reboot after crash.
After cutting out some stuff (splash + icons) and adjusting some settings (eventually the cache/iram ratio and various others) I saw wifi connection attempts, but never success until altering those settings at which point it got to mqtt connection attempts+failure+reboot, always being a memory related crash when I had the exception decoder working (pio seems to remove the elf unexpectedly based on what I pick sometimes).
Adding heap logging, and exploring the map file showed we're crazy low in available heap at boot, and even cleaning up things like littlefs after parseSecrets is done; not creating strings on each wifi attempt (when using wifi multi) and others didn't resolve.

Think if we f-string the world we get back some ram, as it's booting with about 10k available which isn't right (gpt5.2 claimed it's being partly taken by strings), although the biggest symbol was libpp.a from the core at about 22k (there was some wildcard talk of that being optimisable to be more in flash, but requires reprocessing an sdk file - or effectively running one xtensa-ar command).

The other one is topics, we're using a lot of memory for each subscription topic, and adding the display one maybe tipped us over the edge.
Chucking out some of the drivers could save some flash, but I'm not sure that's entirely where our problem is...

The branch with some commits showing possibly useful flags in the platformio ini is https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/tree/esp8266-save-space-3

The useful log bit showing the lack of heap was along the lines of:

WipperSnapper Demo Starting...
Boot heap: 10080
Boot max free block: 9416
Boot heap fragmentation (%): 7
Adafruit.io WipperSnapper
-------Device Information-------
Firmware Version: 1.0.0-beta.121
Board ID: feather-esp8266
Adafruit.io User: tyeth
WiFi Network: free4all
MAC Address: C8:C9:A3:90:2E:9F
Free heap: 10080
Max free block: 9416
Heap fragmentation (%): 7
Running WiFi connect (ESP8266 pre-MQTT)...
Free heap before WiFi connect: 10040
Max free block before WiFi connect: 9416
Heap fragmentation before WiFi connect (%): 7
Establishing network connection...
Performing a WiFi scan for SSID...Skipping WiFi scan on ESP8266
Connecting to WiFi (attempt #0)
Free heap before connect: 10040
WiFi.begin('free4all')
WiFi.status(): 3
Free heap after connect: 9296
Free heap after WiFi connect: 9296
Max free block after WiFi connect: 8544
Heap fragmentation after WiFi connect (%): 9
Generating device's MQTT topics...
Subscribing to b2d DISPLAY topic:
tyeth/wprsnpr/io-wipper-feather-esp826615946144/signals/broker/display
Subscribed to b2d DISPLAY topic!
Heap after topic allocation: 960
Max free block after topic allocation: 896
Heap fragmentation after topic allocation (%): 7
Running Network FSM...
Connected to WiFi!
Connecting to AIO MQTT (attempt #0)
WiFi Status: 20
MQTT Connection Error: -1
Connection failed
Unable to connect to Adafruit IO MQTT, retrying in 3 seconds...

[brentru]

@tyeth Thanks for exploring this in detail

The other one is topics, we're using a lot of memory for each subscription topic, and adding the display one maybe tipped us over the edge.

This shouldn't be a problem in v2, thankfully.

we're crazy low in available heap at boot

8266 has 80K total heap, but a lot of it can be taken up by the networking stack. I'm not sure if it's taking up 70K of heap, though. It might be worth profiling earlier versions of WS, before we added display and other features in.

[DoctorWho8]

I am against stripping out I2C availability for this platform.

[tyeth]

We'll likely keep everything except the new displays on esp8266 at least for v1.

I think Brent and I were in favour of restricting the esp8266 to version 1 [2 expected this year], but Limor has suggested we keep it going in V2 but with feature gating [i.e. no displays etc]

[DoctorWho8]

@tyeth that I'll support.

[DoctorWho8]

I'm still supporting the decision.

[brentru]

@DoctorWho8 I've had some time this week to take a crack at this, the results are for WipperSnapper v1 (aka main). v2, which isn't out yet, has lots of space-saving reductions so I'm less concerned about that but I'll forward-port these changes to v2 as well.

Current main build of WipperSnapper

RAM:   [==========]  96.9% (used 79396 bytes from 81920 bytes)
Flash: [======    ]  64.7% (used 675507 bytes from 1044464 bytes)

Updated ESP8266 build
What Changed (so far, I'm going to make more adjustments to give it some more headroom)

• Serial print now uses the F() macro on ESP8266 MCUs to optimize for space
• ESP8266 display support no longer includes assets/ like the splash screen or status bar icons.

RAM:   [======    ]  62.8% (used 51456 bytes from 81920 bytes)
Flash: [======    ]  63.1% (used 659247 bytes from 1044464 bytes)

[DoctorWho8]

I see. But will this allow me to install stuff onto any of the ESP266 devices that are covered?