skip all the byecode hex data, it's adequately checked
by the disassembly just below
This was tripped up because in exactly the right conditions some qstr
could be of the form 'xx 63' and make the expression `\.\+63` match
something other than what was intended.
This test was re-worked upstream for mpy version 6 so it'll be a conflict
to resolve when we get to that. :-/
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.
On my i5-1235U laptop this speeds LTO "partition=balanced" builds
substantially, because each "partition" can be run on a separate
CPU thread. I used "pygamer" as my test build with a parallelism of
`-j4`, and took the best elapsed time reported over 4 builds.
The improvement was from 34.6s to 24.0s (-30%).
A link-only build (rm build-pygamer/firmware.elf; make -j...) improved
from1 17.4s to 5.1s (-70%)
The size of the resulting firmware is unchanged.
Boards that are nearly full use "-flto-partition=one" to improve code
size optimization. When LTO partition is "one", this feature doesn't help
but it doesn't seem to negatively affect anything either (tested
building trinket_m0)
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
