.. inline-unit-growth was the same across all boards, and the highest
max-inline-insns-auto parameter was shared across 2 of 5 boards, so it's
worth a little work to follow the DRY principle
When adding the ability for boards to turn on the `@micropython.native`, `viper`, and `asm_thumb` decorators it was pointed out that it's somewhat awkward to write libraries and drivers that can take advantage of this since the decorators raise `SyntaxErrors` if they aren't enabled. In the case of `viper` and `asm_thumb` this behavior makes sense as they require writing non-normative code. Drivers could have a normal and viper/thumb implementation and implement them as such:
```python
try:
import _viper_impl as _impl
except SyntaxError:
import _python_impl as _impl
def do_thing():
return _impl.do_thing()
```
For `native`, however, this behavior and the pattern to work around it is less than ideal. Since `native` code should also be valid Python code (although not necessarily the other way around) using the pattern above means *duplicating* the Python implementation and adding `@micropython.native` in the code. This is an unnecessary maintenance burden.
This commit *modifies* the behavior of the `@micropython.native` decorator. On boards with `CIRCUITPY_ENABLE_MPY_NATIVE` turned on it operates as usual. On boards with it turned off it does *nothing*- it doesn't raise a `SyntaxError` and doesn't apply optimizations. This means we can write our drivers/libraries once and take advantage of speedups on boards where they are enabled.
We weren't correctly collecting the start and stop sequences. As
a result, the GC would free the space and allocate other info
there.
Thanks to JacobT on Discord for the bug report!
Whenever there is more than one argument, delegate the operation to
namedtuple_make_new. This allows other circuitpython-compatible
idioms, like with keywords
time.struct_time(tm_year=2000, tm_mon=1, tm_mday=1, tm_hour=0,
tm_min=0, tm_sec=14, tm_wday=5, tm_yday=5, tm_isdst=-1)
with 9 positional arguments, etc.
The only vaguely plausible CPython behavior still not permitted in
CircuitPython that I found is constructing a timetuple from a length-9
list, a la
time.struct_time(list(time.localtime())
Even better, by getting rid of an error message, the build shrinks a
tiny bit.
This doesn't cover ALL the cases that CPython permits for construction
of a struct_time, but it at least makes constructing from any namedtuple
work.
Closes: #2326
The sample width register was never set, so all samples were played
as though they were 16 bit.
After this change, 8-bit samples no longer produce audio on the MAX 98357A
BOB, because only 16-, 24-, and 32-bit samples are supported by the
hardware. This will be addressed by a future change to pad samples to
16 bits; see #2323 and the 98357A datasheet page 6.
The meaning of the "single channel" parameter is not well-documented,
but in fact it seems that "true" must be passed or else the returned
channel_count is always 1. This caused stereo samples to be played
incorrectly.
(or deinitialized, for those of us on this side of the pond)
Otherwise, a sequence like
```
audio = audiobusio.I2SOut(bit_clock=board.D6, word_select=board.D9, data=board.D10)
sine_wave_sample = audiocore.RawSample(sine_wave)
audio.play(sine_wave_sample, loop=True)
del audio
```
could free the memory associated with audio without stopping the
related background task. Later, when fresh objects are allocated within
a now-freed memory region, they can get overwritten in the background
task, leading to a hard crash.
This presumably can affect multiple I2S implementations, but it was
reported against the nRF one.
This caused two problems when playing unsigned samples:
* When an even number of samples were present, it "worked" but only
every other sample was copied into the output, changing the waveform
* When an odd number of samples were present, the copy continued beyond
the end of the buffers and caused a hard fault
