added RPi Pico (rp2040)

[j-enns]

added support for Raspberry Pi Pico (rp2040 based chip) i kept as much of the original program method as reasonable. changes of note:

• no timers used: audioUpdate is called every PWM cycle
• no analog interrupt: the ADC runs a round robin across all inputs and writes the data to the FIFO then DMA writes the FIFO data to analog_readings[] after maximum DMA transfers, an interrupt triggers a DMA restart (~51 minutes)

[tfry-git]

Hi!

Nice work! ... and so it may sound strange if I say, I was afraid this would happen.

We're in the middle of a big overhaul of the platform specific code, and, as it happens, there's even an RP2040 port on top of that in the making: https://github.com/sensorium/Mozzi/pull/145

Not all is lost, however: I like your timerless approach to output, and we should definitely use that. I also hadn't taken care of randomization, so far. Regarding analog readings. Overall, I'd like to make sure, the internals do not diverge too much, however, which is why in my approach, I used a much more cumbersome approach, that fits into the AVR logic, however. Of course the RP2040 is not the only MCU that can do asynchronous round-robin readings all by itself, and we may want to leverage that, sooner of later, but for that, I'd like to come up with a consistent approach, first.

In summary, despite your great work, we won't be able to merge this as is. But we'll definitely want to merge parts of it, after https://github.com/sensorium/Mozzi/pull/145 is in (including due credit)!

Regards Thomas

[j-enns]

i assumed i wasn't the only person working on a port to the pico. breaking apart platform specific code will be so much nicer for future ports, looking forward to it.

i am glad i did the work, even if it was re-inventing the wheel. i leaned a lot: about mozzi, the pico, and programming in general.

[tomcombriat]

Wow, nice things there!

I have a curiosity question: with the audio input not linked to a timer, is it possible that the rate of acquisition will vary with time (jitter)? For instance when the CPU is more busy, the audio hook will run slower (compensated in output by the buffer) leading to a slight decrease in acquisition rate for some time?

Absolutely have to get inspired by this for dma on teensy!

[j-enns]

that is a good point about the audio input. i hadn't thought of that, or noticed it in my limited testing. if updateControl takes more cpu time than 1 sample, it will create a delay every control_rate_hz.

not using the analog interrupt must have made me miss it.