Revert to old dynamically allocated memory for low-memory ESP32 devices
Potentially fixes: #8732 #8729
Effectively reverts https://github.com/meshtastic/firmware/commit/9211b1bb4b0cf9fcfa6a889cbab49938743f7414 for ESP32 devices without PSRAM, like my Lilygo V2 1.6.1.
All versions later have ~20kB less heap, making them slow and unresponsive when using with Wifi (App cannot connect, using API is very slow, regular network dropouts).
This reverts that change for plain ESP32 devices that have no PSRAM, which I assume would be used if present.
🤝 Attestations
- [x] I have tested that my proposed changes behave as described.
- [x] I have tested that my proposed changes do not cause any obvious regressions on the following devices:
- [x] Heltec (Lora32) V3
- [ ] LilyGo T-Deck
- [ ] LilyGo T-Beam
- [ ] RAK WisBlock 4631
- [ ] Seeed Studio T-1000E tracker card
- [x] Other (please specify below)
- [x] Lilygo T3 V2 1.6.1
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
After leaving the device running for a while, the heap usage still creeps up, and at the 88-90% mark the device starts to drop IP connectivity (Mesh node activity seems to be less affected).
It would be nice to identify what is leaking memory.
@jp-bennett TBH I don't think it's a memory leak in the classical sense (memory gets malloc()d and forgotten), but the dynamic allocation over time allocates the same amount of memory as was pre-allocated without that patch. It was worth a try, but we (me and some participants in the linked issues) now think it its also caused by some bloat creeping in since 2.6.x, and a feature-reduced build for non-PSRAM devices (or an expert optimizing the code for memory usage) is probably necessary.
If a maintainer clearly agrees, I am happy to close the PR without a merge, clearly even in my less-populared area the memory allocated quickly reaches the same amount as pre-allocated.
The change definitely has not the intended effect for more than a few minutes, even stripping out other optional features does not. So I cancel this, sorry to bother...