By pausing audio during flash writes, the worst screeching of #8121
is avoided. I don't consider this a full fix, but it greatly improves
the by far most common scenario in which the problem occurs.
Tested on rp2040 prop feather with a midi synth playing arpeggios. When
writing to the flash e.g., with
```
dd bs=512 count=32 if=/dev/zero of=/media/jepler/CIRCUITPY/boop
```
the audio goes "tap tap tap tap" during the flash write instead of the
squawking.
This isn't a 100% fix; it will still glitch out, including during USB
enumeration which must be taking a long time without servicing background
tasks. Add a delay if not usb-connected at startup ameliorates this
greatly.
This adds a check to make sure that SDA and SCL are in a sane condition
before starting any I2C operation. If they are not it tries to rectify it,
and then returns an error code if unable to do so.
on specific SCK/MOSI/MISO pins, the `common_hal_busio_spi_construct`
method always skip miso pins which will lead to a `invalid pin`
exception when SPI initilized
In my testing, the feather bluefruit can do 12 voices at 48kHz!
This is a simple case (no LFOs, no ring modulation) so other situations might
require a lower sample rate, fewer voices, or both.
The sound is a little artifacty & low-fi but I think that's down to the speaker
& use of PWM instead of I2S.
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.
