* Always clear the peripheral interrupt so we don't hang when full
* Store the ringbuf in the object so it gets collected when we're alive
* Make UART objects have a finaliser so they are deinit when their
memory is freed
* Copy bytes into the ringbuf from the FIFO after we read to ensure
the interrupt is enabled ASAP
* Copy bytes into the ringbuf from the FIFO before measuring our
rx available because the interrupt is based on a threshold (not
> 0). For example, a single byte won't trigger an interrupt.
Since the datasheet cast some doubt on the strength of the "rosc_hw->randombit",
I use the SHA256 hash function to create a high quality random seed
from random values of uncertain entropy, as well as to generate a sequence
of random values from that seed using SHA256 as a cryptographically-secure
random number generator.
In practice, it produces over 100kB/s of random data which does not
have any gross problems according to _PractRand_.
@Jerryneedell noticed that this problem affected strips short enough
to not use the DMA peripheral, thanks for the hot tip!
Instead of checking for background tasks after every byte transfer,
try up to 32 transfers before attending to background tasks.
This fixes the problem I was seeing on my 5-pixel circuit.
Closes#4135.
This makes all the following work:
* normal microcontroller.reset()
* reset into safe mode or UF2 bootloader via microcontroller.on_next_reset()
* reset into UF2 bootloader via the "1200 baud trick"
The implementation of reset_cpu is from micropython.
The RP2040 is new microcontroller from Raspberry Pi that features
two Cortex M0s and eight PIO state machines that are good for
crunching lots of data. It has 264k RAM and a built in UF2
bootloader too.
Datasheet: https://pico.raspberrypi.org/files/rp2040_datasheet.pdf
