* Enable dcache for OCRAM where the VM heap lives.
* Add CIRCUITPY_SWO_TRACE for pushing program counters out over the
SWO pin via the ITM module in the CPU. Exempt some functions from
instrumentation to reduce traffic and allow inlining.
* Place more functions in ITCM to handle errors using code in RAM-only
and speed up CP.
* Use SET and CLEAR registers for digitalio. The SDK does read, mask
and write.
* Switch to 2MiB reserved for CircuitPython code. Up from 1MiB.
* Run USB interrupts during flash erase and write.
* Allow storage writes from CP if the USB drive is disabled.
* Get perf bench tests running on CircuitPython and increase timeouts
so it works when instrumentation is active.
This 2-in-1 PR started with the goal of support the Bangle.js 2
smartwatch with *no USB*.
* Adds "secure" DFU build support with a committed private key.
* Adds 3-bit color support with one dummy bit for the JDI memory display
* Allows nrf boards to have a board_background_task() run in RUN_BACKGROUND_TASK.
This is needed because the Bangle.js 2 uses the watchdog to reset.
* Renamed port_background_task() to port_background_tick() to indicate it
runs on tick, not RUN_BACKGROUND_TASK.
* Marks serial connected when the display terminal is inited. This means
that safe mode messages show up on the display.
ACep, 7-color epaper displays also pack 3 bits in 4. So, I added that
support as well.
* Adds 3-bit ACeP color support for 7-color e-paper displays. (Not
watch related but similar due to color depth.)
* Allows a refresh sequence instead of a single int command. The 7" ACeP
display requires a data byte for refresh.
* Adds optional delay after resetting the display. The ACeP displays
need this. (Probably to load LUTs from flash.)
* Adds a cleaning phase for ACeP displays before the real refresh.
For both:
* Add dither support to Palette.
* Palette no longer converts colors when set. Instead, it caches
converted colors at each index.
* ColorConverter now caches the last converted color. It should make
conversions faster for repeated colors (not dithering.)
* write any partial message
* instead of "..." show a sensible (translatable) message
This does slightly lower the amount of data that can be printed,
and makes the exact amount dependent on the language. However, if boot.py
intentionally needs to produce larger amounts of output, it can
deliberately mount the filesystem in RW mode and perform any writes needed.
In that case it's up to the boot.py to choose an appropriate way to
limit the number of writes if needed for the application.
Now, open wifi works on Pico W, so this closes#7438.
For the web workflow it's now OK to either
* specify an empty password string (as before)
* not have the CIRCUITPY_WIFI_PASSWORD key at all (new functionality)
This may help address #7409 if the underlying cause is the deterministic
volume ID. However, not all boards have working urandom (samd21
at least does not) so a couple of fallbacks are attempted when it fails.
I verified that on a pico_w, each `storage.erase_filesystem()` gives
a distinct 32-bit volume ID (pico_w's urandom can never fail)
* Set nonblock on all accepted sockets. Not just ones for user code.
* Close an open websocket if another is accepted.
* Set debug level to INFO rather than DEBUG because DEBUG crashes
on ESP32-S3 USB OTG.
When the USB serial buffer is full, the Ctrl-C code to send
KeyboardInterrupt can't be sent, which creates a problem if you've
pasted code or otherwise filled the buffer and need to recover.
A similar problem affects advanced UIs that interact with CircuitPython
and may send characters when they're unexpected, such as mu when it
tries to move the cursor based on the user clicking on the screen.
The main way forward seems to be to use some kind of message that can
still reach CircuitPython when its internal serial recieve buffer is full.
RS232 defines a "break" signal, in which the transmitting device holds its
data line in the "space" state for many entire character times. This still
exists in the world of USB serial.
This does work, sort of, except that your host computer software will need
to properly handle blocking serial writes; tio can send a break with
the **ctrl-c b** sequence, but this only works if it hasn't yet written
too much data, so it doesn't actually help in most situations :-/
