Any two consecutive pins can be used for an IncrementalEncoder
Testing performed: Put a synthesized (few hundred counts per second) quadrature signal into GP2/3 and read the encoder out. Performed filesystem operations at the same time to stress test it.
The reasons for not using common_hal_rp2pio_statemachine_readinto are commented on.
This can be used where the standard API calls for a list of pins, to check that they satisfy the requirements of the rp2pio state machine, e.g.,
```python
def __init__(self, pin_a, pin_b):
if not rp2pio.pins_are_sequential([pin_a, pin_b]):
raise ValueError("Pins must be sequential")
```
* 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.
This adds I2SOut and PDMIn support via PIO.
StateMachines can now:
* read and read while writing
* transfer in 1, 2 or 4 byte increments
* init pins based on expected defaults automatically
* be stopped and restarted
* rxfifo can be cleared and rxstalls detected (good for tracking when
the reading code isn't keeping up)
Fixes#4162
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_.
Also found a race condition between timer_disable and redraw, which
would happen if I debugger-paused inside common_hal_rgbmatrix_timer_disable
or put a delay or print inside it. That's what pausing inside reconstruct
fixes.
So that the "right timer" can be chosen, `timer_allocate` now gets the `self`
pointer. It's guaranteed at this point that the pin information is accurate,
so you can e.g., find a PWM unit related to the pins themselves.
This required touching each port to add the parameter even though it's
unused everywhere but raspberrypi.
@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
