ESP32: Set maximum heap size in mpconfigport.h.

[glenn20]

The problem: Too much memory allocated to heap on ESP32S2.

Micropython allocates too much RAM to the microython heap on ESP32S2 leaving insufficient RAM available for other IDF functions (causing panics in networking and espnow code). On the ESP32 101563 bytes is allocated to the heap by default. On the ESP32S2 this is ~120kB.

NOTE: when this this bug is resolved the default heap size on ESP32S2 will increase to ~160kB.

This fix: Set a maximum allowed value for the heap size.

Micropython currently allocates the largest available memory block to the micropython heap. This PR allows the maximum allowed heap size to be #defined as MICROPY_HEAP_SIZE_MAX. The default value is set to 104000 in mpconfigport.h and can be overridden in the board definition files: mpconfigboard.h.

With this default setting the espnow and wireless functions no longer generate panics on the ESP32S2.

Other approaches

#6785 allows the heap size to be set at run time (from NVS variables) which is a useful and powerful feature.

Nonetheless, it should be possible to deterministically set a reasonable maximum for the heap size"out of the box" in a compiled image that allows normal operation of an ESP32XX chip irregardless of exactly how the memory on the chip is fragmented.

[tom-van]

Also see #7214

[tom-van]

@glenn20 I agree we desperately need an easy way to re-partition python and IDF heaps for S2 without SPIRAM (and likely also for S3 w/o SPIRAM and C3 as well).

TBH the heap limits spread to board configs scare me little bit. It just delegates responsibility for heap size to board supporters so we could end up with the mess where one py program works on some S2 boards and does not on others with the same SoC just because of different heap limit setting.
The board already defines SoC type and if SPIRAM is present or not and there no other relationship between the board and the size of heap required.

I would prefer more reasonable default allocation (e.g. #7214) and add an instrument to change the setting during runtime like #6785. The ideal solution would be to get rid of static heap partitioning. I remember I found a proposal to reclaim parts of allocated py heap when IDF heap getting nearly exhausted but I'm not able to find it now.

[glenn20]

Thanks for following up @tom-van. I believe my PR essentially does set a reasonable default allocation as you suggest (in mpconfigport.h). This is a "global" default for the esp32 port. I just note that specific boards can override that in mpconfigboard.h if it should prove necessary for a specific board. I think I have implemented something like what you suggested. Does that make sense?

Unfortunatelty, due to my lack of diligence, I didn't see your issue before I submitted my PR.

[dpgeorge]

Nonetheless, it should be possible to deterministically set a reasonable maximum for the heap size"out of the box" in a compiled image that allows normal operation of an ESP32XX chip irregardless of exactly how the memory on the chip is fragmented.

I agree with this.

TBH the heap limits spread to board configs scare me little bit

I also agree with this.

Instead of being a per-board config it could be an internal per-chip (S2 vs S3 etc) config. Eg on ESP32 the limit would be 104000, while on ESP32S2 it would be 80000. That's effectively what #7214 proposes, just in an algorithmic way as a fraction of the total heap size.

[dpgeorge]

In 23b1a4e, at most 1/2 of total IDF heap is allocated to the MicroPython heap.

So this PR can be closed (it may still be beneficial for a user to somehow configure the amount of MP heap, but I think via compilation options is not as good as dynamically).