In #2013, @danh says:
My choice of where to put the semicolon is deliberate,
so that we can say
RUN_BACKGROUND_TASKS;
not have a redundant semicolon, and not confuse C code formatting.
.. such as namedtuple and attrtuple objects. This is the same
predicate used elsewhere in the file to check for adequate compatibility
between the types.
This was discovered due to crashing `time.time()` on the nrf port.
Closes: #2052
Otherwise, examples like the one attached to the related issue fail
because tud_hid_ready never returns true.
Testing performed: Adapted the example to nrf particle xenon (it was
handy), removed dependency on IR, verified that the problem occurred
before this change, and that it was fixed after this change.
Closes: #2048
Some ports which actually don't have audioio or audiobusio were still
calling into audio_dma_background(). This wasn't an error until
the assignment to audio_dma_state in audio_dma_stop was added, though
it's not clear why.
audio_dma_stop can be reached twice in normal usage of AudioOut.
This may bear further investigation, but stop it here, by making the
function check for a previously freed channel number. This also prevents
the event channel from being disabled twice.
The first stop location is from audio_dma_get_playing, when the buffers
are exhausted; the second is from common_hal_audioio_audioout_stop when
checking the 'playing' flag.
As identified in #1908, when both AudioOut and PDMIn are used, hard
locks can occur. Because audio_dma_stop didn't clear audio_dma_state[],
a future call to audio_dma_load_next_block could occur using a DMA
object which belongs to PDMIn.
I believe that this Closes: #1908 though perhaps it is still not the full
story.
Testing performed: Loaded a sketch similar to the one on #1908 that
tends to reproduce the bug within ~30s. Ran for >300s without hard
lock. HOWEVER, while my cpx is no longer hard locking, it occasionally
(<1 / 200s) announces
Code done running. Waiting for reload.
(and does so), even though my main loop is surrounded by a 'while True:'
condition, so there are still gremlins nearby.
It is possible for this routine to expand some inputs, and in fact
it does for certan strings in the proposed Korean translation of
CircuitPython (#1858). I did not determine what the maximum
expansion is -- it's probably modest, like len()/7+2 bytes or
something -- so I tried to just make enc[] an adequate
over-allocation, and then ensured that all the strings in the
proposed ko.po now worked. The worst actual expansion seems to be a
string that goes from 65 UTF-8-encoded bytes to 68 compressed bytes
(+4.6%). Only a few out of all strings are reported as
non-compressed.
