Before this, a background callback that was on the list when
background_callback_reset was called could have ended up in a state
that made it "un-queueable": its "prev" pointer could have been non-NULL.
The getter for vectorio.Polygon#points was not updated with the data type change of the stored points list.
This moves the implementation to shared_module and updates the data type to reflect the actual state.
BHB needs better accuracy from the ADC readings. To avoid changing the ADC configuration for all boards or adding complexity to AnalogIn, I implemented a custom user module to allow the BHB to talk to the ADC in the way that it needs to. I'm open to other approaches here, but this seemed like the least invasive and complex option.
The newest version for the Stage library for PewPewM4 no longer contains
embedded graphics, which frees enough space in flash to enabled back
AnalogIO and also add USB_HID. There is still ~192 bytes left free.
If new additions to CircuitPython make it grow further, we can disable
USB_HID again.
We're moving towards a co-processor model and a Wiznet library is
already available.
New native APIs will replace these for chips with networking like the
ESP32S2 but they won't be these.
A background callback must never outlive its related object. By
collecting the head of the linked list of background tasks, this will
not happen.
One hypothetical case where this could happen is if an MP3Decoder is
deleted while its callback to fill its buffer is scheduled.
On my hardware, esptool reports
MAC: 7c:df:a1:02:6c:b8
after this change, the USB descriptor says SerialNumber: 7CDFA1026CB8
and microcontroller.cpu.id has
>>> "".join("%02x" % byte for byte in microcontroller.cpu.uid)
'c7fd1a20c68b'
Note that the nibble-swapping between USB and cpu.uid is typical.
For instance, an stm32 board has USB SerialNumber
24002500F005D42445632302 but hex-converted microcontroller.cpu.id
420052000f504d4254363220.
CALLBACK_CRITICAL_BEGIN is heavyweight, but we can be confident we do
not have work to do as long as callback_head is NULL.
This gives back performance on nRF.
Before this, the mp3 file would be read into the in-memory buffer
only when new samples were actually needed. This meant that the time
to read mp3 content always counted against the ~22ms audio buffer length.
Now, when there's at least 1 full disk block of free space in the input
buffer, we can request that the buffer be filled _after_ returning from
audiomp3_mp3file_get_buffer and actually filling the DMA pointers. In
this way, the time taken for reading MP3 data from flash/SD is less
likely to cause an underrun of audio DMA.
The existing calls to fill the inbuf remain, but in most cases during
streaming these become no-ops because the buffer will be over half full.
In time, we should transition interrupt driven background tasks out of the
overall run_background_tasks into distinct background callbacks,
so that the number of checks that occur with each tick is reduced.
