[closed] How to use DMA in earl's core together with PWM

[petervflocke]

Hi Earl,
Dear all,
I do like your arduino-pico core and appreciate the possibility to use pico sdk!
Apparently it is not as straightforward as I've initially thought.

I'd like to use DMA for PWM control, based on a great idea from BirchJD.
This (link) is a pico sdk based repo which produces a nice sound. PoC works as desired.

I tried to port it to your Arduino core with this code (link) and I failed. A simple "copy&paste" does not work. It produces no sound in compare to the pure c-based PoC code.

The main code to be ported is just a few lines in the file WavPwmAudio.cpp - same for both versions: sdk and arduino code.

I think I have read that Arduino uses some PWM channels, so we are not free to use all of them. Before I will spend Xmas on reading, I would like to ask for your opinion and or support. Do you see a method to port the code? This allows to add something more than beeps to the arduino pico projects, without any (almost) additional hardware.

Cheers and thank you in advance!
Peter

[earlephilhower]

Unfortunately the links in your post don't seem to work. All seem 404'd.

Anyway, this is something I was thinking about myself but never got around to doing. The idea is to set up a high frequency PWM signal on a pin and then use the DMA engine, on a timed transfer to send samples to it.

There are no PWM units used in the core unless you do analogWrite so it's all at your disposal.

I would start with the I2S library and the AudioRingBuffer. You'll need to config the DMA to use a timer, not a FIFO free signal. DMA target will be the PWM value reg for the associated pin, not the PIO FIFO. The PWM channel will need to be config'd at the beginning and the audio samples received from the app will probably need to be scaled to the max PWM count.

It shouldn't be rocket science, but it probably is a good afternoon's hacking. :)

[petervflocke]

@earlephilhower
Sorry I did not like my answer I gave you, that I had updated the code to keep it consistent - it is a stupid statement.
Actually I still haven't found 100% proper answer. For now it is like that "me looking at the code"

The GPIO 0 hardcoded in the PwmSliceNum = pwm_gpio_to_slice_num(0); does not play any role, since the GPIO number is reflected in this line.
dma_channel_configure(WavPwmDmaCh, &WavPwmDmaChConfig, (void*)(PWM_BASE + PWM_CH0_CC_OFFSET), &(WavPwmData[2]), (WavPwmData[0] + (65536 * WavPwmData[1])) / 2, false);

This reflects the target GPIO output pin:
PWM_**CH0**_CC_OFFSET points to GPIO16 (CH0)
Switching to GPIO6 results in:
PWM_**CH3**_CC_OFFSET points to GPIO6 (CH3)
... and so on according to:

1. https://github.com/majbthrd/pico-debug/blob/master/rp2040/hardware/regs/pwm.h
2. and the visual mapping: https://cdn-shop.adafruit.com/970x728/4864-04.png

For anybody googling this out, if you want to change the PWM output pin you have to reflect this in the PWM_**CH??**_CC_OFFSET value.

I still need to read the SDK and understand how DMA and hardware PWM for RP2040 works. But now I have at least working code!

Cheers
Peter

[Andy2No]

I think you'd like the lectures by Hunter Adams, on YouTube. I haven't watched them all, but what I have watched has been very informative, and he backs them up with code examples on his own website, in most cases:

This one covers using DMA with ADC. There's a chapter index in the description:
https://www.youtube.com/watch?v=TGjUHChO1kM

This one covers hardware PWM:
https://www.youtube.com/watch?v=-OoGz9A6o2Q

[petervflocke]

Hi Andy,

I think you'd like the lectures by Hunter Adams, on YouTube

Indeed, the complete channel looks very promising. I like the content of the lectures and the way of explanation. Thank you for your recommendation!

Have a great day!
Peter

[petervflocke]

Just in case you would like to see, or listen to: https://youtube.com/shorts/isAoaTnkfzQ

[Andy2No]

Nice 👍

[earlephilhower]

Check #1076, @petervflocke . I spent a couple afternoons adapting the I2S to PWM and it works pretty nicely IMHO!

[petervflocke]

Hi Earle,
"Hey Macarena" works well.
I'm wondering why you decided to implement a buffer as a list instead of simple "array" of data.
As long as the data come from a stable source e.g. flash, instead of network stream or slow sd card we can avoid processor and memory overhead to play it. I can imagine a ring buffer for unstable or slow sources.
What do you think?

[earlephilhower]

The idea was to make it interchangeable w/the I2S setup where most folks are computing things on the fly (i.e. decoding MP3s or generating speech), so any little linked list overhead or memcpy would be minimal. Even for PWM, you need to touch every work anyway (since WAVs are 16b signed and PWM is <16b and unsigned) so you're not really saving anything.

I can see potentially a "give me a buffer" or "take this whole buffer" API, but it's not high on my prio list. PRs always appreciated. :)

[petervflocke]

The idea was to make it interchangeable w/the I2S setup where most folks are computing things on the fly (i.e. decoding MP3s or generating speech),

I see! That makes absolutely sense. Thanks for your clarification and the links, especially for the speech generator. I need something similar for my project, where I use pre-generated samples for the time being.

Even for PWM, you need to touch every work anyway (since WAVs are 16b signed and PWM is <16b and unsigned) so you're not really saving anything.

For a "fixed" background music and sound fx I convert WAVs to PWM offline, so I can point to buffer, fire and forget.

I can see potentially a "give me a buffer" or "take this whole buffer" API, but it's not high on my prio list. PRs always appreciated. :)
I was thinking to tinker your code and add something like, "take this whole buffer" and play it for me and do not bother my precious process, sweating with sprites anyway.

Have a great day!
Peter

[earlephilhower]

Neat! You'll probably still want to use chained, smaller buffers, of course, to keep the latency down when your little sprite needs to go "beep" or "boop." 😆