by including a comment ".. jinja" anywhere in the file. By convention,
this should be at the top.
os.getenv will use this so it can render a 'supported boards' list.
The picodvi PR #7880 switched the saved word to the watchdog
register since it reworked the RAM layout. This works for
reset_into_safe_mode because the watchdog scratch registers are
preserved by soft resets. They *aren't* preserved for pressing the
reset button. So it broken manual safe mode. Switch back to using
RAM to store the saved word but use the pico-sdks "uninitialized"
designation instead of a fixed location.
Also fixes USB host feather status neopixel by setting the power
pin.
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
