.. and switch makerfabs tft7 over to it as a test.
We have our existing way of "reserving" PSRAM for esp-idf (we actually
control it all but add back the "reserved" part). However, this does
not work with off the shelf esp_lcd, which only will allocate a
framebuffer in PSRAM if CONFIG_SPIRAM_USE_CAPS_ALLOC (or CONFIG_SPIRAM_USE_ALLOC)
is defined, not if CONFIG_SPIRAM_USE_MEMMAP is.
This new way is possibly compatible with more esp-idf code, but it complicates
CircuitPython's initial startup since nothing until port_heap_init is
permitted to use the CP heap or supervisor allocator. In practice this
seems to be OK today.
Right now this doesn't change the setting across all boards with PSRAM and so
it does not revert esp-idf to its prior state. Instead, what I'm thinking is
that we can do it during or just after the IDF5 update when sdkconfig files
will be getting an overhaul anyway.
With DEBUG build and a consle UART, this would occur early during startup on makerfabs tft7:
```
I (0) cpu_start: Starting scheduler on APP CPU.
I (10) uart: queue free spaces: 20
***ERROR*** A stack overflow in task uart_event_task has been detected.
Backtrace: 0x403786f2:0x3fce9f40 0x403820a9:0x3fce9f60 0x403850da:0x3fce9f80 0x40383a7d:0x3fcea000 0x40382158:0x3fcea030 0x4038214e:0xa5a5a5a5 |<-CORRUPTED
```
Decoded backtrace was not enlightening:
```
0x403786f2: panic_abort at /home/jepler/src/circuitpython/ports/espressif/build-makerfabs_tft7/esp-idf/../../esp-idf/components/esp_system/panic.c:408
0x403820a9: esp_system_abort at /home/jepler/src/circuitpython/ports/espressif/build-makerfabs_tft7/esp-idf/../../esp-idf/components/esp_system/esp_system.c:137
0x403850da: vApplicationStackOverflowHook at /home/jepler/src/circuitpython/ports/espressif/build-makerfabs_tft7/esp-idf/../../esp-idf/components/freertos/port/xtensa/port.c:407
0x40383a7d: vTaskSwitchContext at /home/jepler/src/circuitpython/ports/espressif/build-makerfabs_tft7/esp-idf/../../esp-idf/components/freertos/tasks.c:3505
0x40382158: _frxt_dispatch at /home/jepler/src/circuitpython/ports/espressif/build-makerfabs_tft7/esp-idf/../../esp-idf/components/freertos/port/xtensa/portasm.S:436
0x4038214e: _frxt_int_exit at /home/jepler/src/circuitpython/ports/espressif/build-makerfabs_tft7/esp-idf/../../esp-idf/components/freertos/port/xtensa/portasm.S:231
0x00000000: ?? ??:0
```
Adding an additional 512 bytes of stack allowed CircuitPython to start
successfully.
This is not working/tested. The display requires an initialization sequence,
and its SPI bus is on the other side of an I2C GPIO expander making things
more difficult.
the `Makefile:...` version broke the shared bindings matrix generation, as
it would fail if esp-idf wasn't in the environment (and we wouldn't want
it to do that much work anyway)
Here's why this helps fix the build error:
If this file does not exist or is out of date, then it is generated
and then the Makefile is re-read.
I don't know why this worked before but stopped now; it must have
to do with the rework of header generation in the MP build system.
Dan Halbert
Scott Shawcroft
Bill Sideris
Jeff Epler
Elviss Kustans
Melissa LeBlanc-Williams
Bob Abeles
Tirtharaj Sinha
Jozsef Kiraly
Dan Halbert
Kattni Rembor