and re-organize so that esp32 s2/s3 don't do as much at reset
.. it's not necessary (because most data is in esp-idf managed memory)
and doing this saves me from having to debug why reconstruct isn't working
properly on that platform.
This needs to be tested on other platforms again before being merged!
tested:
* board.LED
* neopixel as status LED
* i2c scan finds lis3dh sensor
* psram capacity
not tested:
* rgb matrix o_O
* the gpio pins
Introduce new `board` properties for matrixportal-style boards:
* MTX_COMMON
* MTX_ADDRESS
These are intended to simplify use of the RGBMatrix constructor:
```py
matrix = RGBMatrix(..., addr_pins=MTX_ADDRESS[:3], **MTX_COMMON)
```
removing the need for sending in the following individual parameters:
* rgb_pins
* clock_pin
* latch_pin
* output_enable_pins
and making construction of a 16/32/64-row display easy by slicing a tuple
of all address pins rather than writing out the individual pins. If it
works out it'll be ported back to the matrixportal m4 as well.
ESP32-S3 defines two additional general use pins in
ports/espressif/peripherals/esp32s3/pins.h, for which
support is missing in the microcontroller module HAL.
esp_ping_new_session can fail, particularly if ping is called quickly
many times in succession.
This is because `esp_ping_new_session` has to do a bunch of stuff
including creating a task and a socket. Calling `esp_ping_delete_session`
doesn't clean up these resources immediately. Instead, it signals the
task to clean up resources and exit 'soon', but 'soon' is defined as 1
second.
When the calls are frequent, the in-use sockets and tasks fill up
available slots—I didn't actually check which resource gets used
up first.
With this change, the ping call will raise an exception instead of
continuing with a call to esp_ping_start that crashes.
Closes#5980 based on my testing on an ESP32S3-N8R2.
