Raspberry Pi Pico / RP2040 support?
xoblite opened this issue · comments
Hi,
I just found this library and it looks quite promising indeed, but it being my current tinkering platform of choice I was wondering whether support for Raspberry Pi Pico / RP2040 (read: including running OS-less, with fundamentals based off the Pico SDK, perhaps including support for running on the second core, etc) has been considered and/or investigated yet? (read: as I just found the library I don't quite know where to start digging myself yet ;) )
https://www.raspberrypi.com/products/raspberry-pi-pico/
https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf
https://github.com/raspberrypi/pico-sdk
Thanks,
BR//Karl (@xoblite)
I don't own one, but i'm almost postiive it will work by a glance at the specs. If it's got an FPU and ~128KB of RAM , it should be fine! I think @dpwe had done some work porting it?
Thanks for the replies! @dpwe, there are some single/double-precision floating point etc functions as part of the SDK Runtime Infrastructure though, would that suffice assuming the raw horsepower is there with the RP2040?
https://www.raspberrypi.com/documentation/pico-sdk/runtime.html#pico_float
https://www.raspberrypi.com/documentation/pico-sdk/runtime.html#pico_double
(etc)
Right. AMY does quite a lot of single-precision FP calculations, so it's going to be an issue.
This table suggests that RP240 floating-point operations are 5-10x slower than on an ESP32-S3, which is pretty good. In that case, you might expect to be able to run up to 10-12 oscillators in real-time on an RP2040.
I think it would be well worth trying. It should run with minimal changes.
Sounds good; any way I can help out? (read: with testing maybe since I only just discovered this library today and hence likely do not yet find my way around it sufficiently to able to adapt the source code as needed)
By the way, your different oscillator types have different FP horsepower requirements too right?
Or would you say "up to 10-12 oscillators" as per above would apply to most/all variants due to other related constraints?
I added a couple of RP2040s to an order i was doing and if someone doesn't get to it first, i should be able to look at porting AMY to it next week.
Individual oscillators should generally take about the same CPU time. Things like FM use multiple oscillators (8) to make a single tone.
Sounds good - I will also receive two more Pico's, a few DACs (SPI 12-bit TH) etc as part of a shipment shortly. Keep me posted? 👍
I mean, the shame is that there's no network on the RP2040 either, so there's a question of how to deliver events. There is, of course, Serial (under Arduino).
What would be really nice would be running AMY directly wired into Micropython...
I don't have any Pi Pico W's, but sure that meets that requirement.
I mention it because the original deployment of AMY was as part of Alles, an ESP32-based wireless "mesh synthesizer".
In general, AMY is an engine that receives events and generates sounds in response. Those command events could come from a separate program running locally, but could also come across a network from a separate "sequencer" device.
I got my rp2040s yesterday and wired it up. AMY was easy to compile for it, no changes needed except to default to PCM_SAMPLES_SMALL as the board I'm using doesn't have enough flash for the larger set. I borrowed the sine_wave example from pico-extras to get I2S online. You can see all the code in the rp2040 branch here.
To try this out:
gh repo clone raspberrypi/pico-extras
gh repo clone raspberrypi/pico-sdk
# Do whatever installs you need for the pico-sdk
gh repo clone bwhitman/amy
cd amy/src
git checkout rp2040
mkdir build; cd build
export PICO_SDK_PATH=../../../pico-sdk
export PICO_EXTRAS_PATH=../../../pico-extras
cmake ..
make && picotool load amy_example.elf
You'll need to change the pins in CMakeLists.txt in src to reflect your i2s setup.
As of right now, we can support only 4 oscillators at once running on a single core at 250MHz. (Compare the ESP32, which can easily handle 32 oscillators per core.) Clearly, the FP or RAM access (for the LUTs) is not working well. I have to do other stuff for the next few days but if someone is interested in checking out this code to see if we're skipping the FP accelerators, that would be helpful.
I've also mailed an RP2040 to Dan to arrive tomorrow, so maybe he gets inspired.
(I do have PICO_DEFAULT_FLOAT_IMPL=pico set, which I do believe to mean we are using the optimized float32 impl.) From page 24 of https://datasheets.raspberrypi.com/pico/raspberry-pi-pico-c-sdk.pdf
Yeah. The table I linked above indicates a 125 MHz Pico is ~10x slower at FP ops than a 240 MHz ESP32-S3. So I wouldn't have been shocked if you'd gotten 1/5th of the performance on the 2x overclocked RP2040, but another factor of 3/4 isn't surprising.
The table distinguishes "Generation" and "Mean calculation". Mean calculation is pretty much pure FP muls, adds, and divides. Generation also includes transcendental functions (sinf, cosf), and is only 5x slower, perhaps reflecting more of the firmware optimization.
I think the table's "Arduino mbed core" numbers reflect not using the RP2040 optimized firmware, and are 5x slower for Generation, 3x slower for Mean calculation.
I'm working on some Raspberry Pi Pico synthesis tools. I'm tied up on another project for a couple of weeks, but I'm pretty sure I'll be able to translate AMY into Forth and use fixed-point / block floating arithmetic to get things to work at a reasonable capacity.
The Forth I'm using, Zeptoforth, will support the Pico W, but I'm not sure when it will be released.
I'm working on some Raspberry Pi Pico synthesis tools. I'm tied up on another project for a couple of weeks, but I'm pretty sure I'll be able to translate AMY into Forth and use fixed-point / block floating arithmetic to get things to work at a reasonable capacity.
The Forth I'm using, Zeptoforth, will support the Pico W, but I'm not sure when it will be released.
Finally getting back to this. Is there documentation on the algorithms in pseudo-code or is all the knowledge in the C code?
I don't think you'll find the kind of thing you're looking for (at least, not specifically corresponding to Amy). It's all widely discussed and described algorithms, but less often in pseudocode.
There's a considerably simpler and more transparent implementation of the DX7/FM synthesis in amy/dx7_simulator.py, but that doesn't have the incremental blocking or message-based control of the C code.
The lookup table + integration algorithms for pulse and sawtooth were based on ideas presented in Miller Puckette's amazing book. But his examples are all in Pd, which is far from pseudocode for a procedural language.
I'm sure there are good code-based introductions to subtractive synthesis (oscillators + filters + envelope generators), but I don't have a specific one to recommend.
DAn.
There's a considerably simpler and more transparent implementation of the DX7/FM synthesis in amy/dx7_simulator.py, but that doesn't have the incremental blocking or message-based control of the C code.
That's OK - I have to do the low-level I/O using the real-time OS capabilities of zeptoforth from the ground up. And I don't need DX7 compatibility; I can run dexed on another board if I want that. I just need to do FM synthesis.
The lookup table + integration algorithms for pulse and sawtooth were based on ideas presented in Miller Puckette's amazing book. But his examples are all in Pd, which is far from pseudocode for a procedural language.
I can figure that out from Pd code.
I'm sure there are good code-based introductions to subtractive synthesis (oscillators + filters + envelope generators), but I don't have a specific one to recommend.
I have a lot of papers on "virtual analog / virtual subtractive" synthesis / band-limited oscillators and filter emulation. I'd be implementing them directly from the algorithms.
DAn.
This is now done, AMY fully supports the RP2040 and works quite well!
Thanks! This saves me a bunch of coding time!