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 :-/
It doesn't need never reset because the status LED is only active
when user code isn't.
This also fixes PWM never reset on espressif so that deinit will
undo it.
Fixes#6223
danh and microdev1 noticed that this ignore pattern was over-broad
and caused added sdkconfig files in boards/ (which should be committed)
to be ignored and not proposed for addition by common tools like
git status, git gui, etc.
This pattern anchors the search so that it only matches in the
ports/espressif directory, so ports/espressif/sdkconfig is ignored
but ports/espressif/boards/example/sdkconfig is not ignored anymore
It's more efficient passing one register-sized structure than 4
arguments or 4 pointers; working on intermediate values of 'int' size
is also more efficient in code size!
On raspberry pi pico w, this increased free flash space by +104 bytes.
It also increased the speed of my testing animation very slightly, from
187fps to 189fps when run 'unthrottled'
This needs thorough testing before it's merged, as we tried
and reverted this once before (#5341 and #5356).
I think that besides checking for tinyusb having "something to do",
the fact that `port_interrupt_after_ticks` and `port_disable_tick`
weren't implemented that was causing a secondary problem.
I've tested this on a pico w over reboot-cycles and ctrl-c-cycles,
with and without drive automounting, with and without serial repl open,
and on a power-only connection.
I didn't notice the problem reported in #5356 after merely implementing
port_idle_until_interrupt; but I did notice that sleeps in general would
take over-long until "something" (like writing to the USB drive) happened;
I think "something" was probably calling port_enable_tick(). When this
problem was happening, sleeps would take a lot longer; for instance,
`sleep(.001)` would take about 1/20s and `sleep(.1)` would take about 1/7s.
