Fixes#2086
When the frequency of a `PWMOut` is change it re-sets the PWM's duty cycle as
well, since the registers have to be re-calculated based on the new frequency.
Unfortunately, `common_hal_pulseio_pwmout_get_duty_cycle`
will return a value very close to, but not exactly, the value passed to `common_hal_pulseio_pwmout_set_duty_cycle`. If the frequency is modified
without the calling code also re-setting the duty cycle then the duty cycle
will decay over time. This fixes that problem by tracking the unadjusted duty
cycle and re-setting the duty cycle to that value when the frequency is changed.
Make changes in asf4_conf even though I think in these cases the
"peripherals" submodule is running the show.
Arduino clocks the DAC at 12MHz but uses the CCTRL setting for
clocking < 1.2MHz (100kSPS).
A fresh clock (6) is allocated for the new 12MHz clock. This matches
the Arduino value, though not the GCLK index.
Modify other settings to more closely resemble Arduino.
In AudioOut, actually clock the waveform data from the timer we set up
for this purpose.
This gives good waveforms when setting AnalogOut full-scale in a loop,
but the rise/fall of waveforms that come from AudioOut are still erratic.
Weirdly, if AudioOut limits its range even slightly (e.g., to 1000..64000)
then the erratic
Note that this will require https://github.com/adafruit/samd-peripherals/pull/26
to be accepted for the submodule update here to work.
Previously, we depended on allocated channels to always be
"dma_channel_enabled". However, (A) sometimes, many operations
would take place between find_free_audio_dma_channel and
audio_dma_enable_channel, and (B) some debugging I did led me to believe
that "dma_channel_enabled" would become false when the hardware ended
a scheduled DMA transaction, but while a CP object would still think it
owned the DMA channel.
((B) is not documented in the datasheet and I am not 100% convinced that
my debugging session was not simply missing where we were disabling the
channel, but in either case, it shows a need to directly track allocated
separately from enabled)
Therefore,
* Add audio_dma_{allocate,free}_channel.
* audio_dma_free_channel implies audio_dma_disable_channel
* track via a new array audio_dma_allocated[]
* clear all allocated flags on soft-reboot
* Convert find_free_audio_dma_channel to audio_dma_allocate_channel
* use audio_dma_allocated[] instead of dma_channel_enabled() to check
availability
* remove find_free_audio_dma_channel
* For each one, find a matching audio_dma_disable_channel to convert
to audio_dma_free_channel
Closes: #2058
.. otherwise, a sequence like
>>> a = audioio.AudioOut(board.A0)
>>> a.play(sample, loop=True)
>>> a.deinit()
would potentially leave related DMA channel(s) active.
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.
