Using the two PIO blocks in RP2040 simultaneously

[alefais]

Hi!

I have in mind a project where my Raspberry Pi Pico is connected to two CODECs instead of only one. Each CODEC processes the audio signal internally, and I would like my RP2040 to perform further processing on the audio data coming from the two CODEC units. I was thinking of using/extending your nice library to implement this logic, and I wanted your opinion on the feasibility of this idea. Since the RP2040 has 2 PIO blocks, I would like to set up both as bi-directional slave and use them simultaneously.
However, I was wondering if there are any hardware constraints to manage two different I2S IN/OUT at the same time.
Given your expertise on the topic, could you give me some guidance on this?

Thanks!

Alessandra

[malacalypse]

You can do this without modifying the existing code at all. Just use two different pio_i2s objects (so each codec has its own dma buffer) and two different dma handlers. Each handler can then synchronize their processing and the combined result however they need to according to your logic.

There are no hardware constraints with this that I can think of offhand, at least. The bidi slaves can share the clock pins if you intend to run them synchronously from the same clock source, only the data pin would need to be unique.

[alefais]

Ok, I will follow your suggestions and start working on my project. Thank you for your time!

[alefais]

Hi,

I'm following your suggestions to develop my project but I'm having a hard time making things work.
I started by using two different pio_i2s and i2s_config objects, and two dma_i2s_handler functions.
I wrote a simple example (see the code snipped below) with Arduino and tested it on my Raspberry Pi Pico. If I invoke a single i2s_program_start_slaved or i2s_program_start_synched on the PIO0 or PIO1 everything is ok, but if I invoke both functions (slaved or synched) on the two pio then the micro panics and freezes.

#include "hardware/clocks.h"
#include "hardware/dma.h"
#include "hardware/i2c.h"
#include "hardware/irq.h"
#include "hardware/pio.h"
#include "i2s.h"
#include "pico/stdlib.h"

static __attribute__((aligned(8))) pio_i2s i2s0;
static __attribute__((aligned(8))) pio_i2s i2s1;

// these are declared as extern const i2s_config in i2s.h 
const i2s_config i2s_config0 = {48000, 256, 32, 10, 6, 7, 8, false};        // fs; sck_mult; bit_depth; sck_pin; dout_pin; din_pin; clock_pin_base;
const i2s_config i2s_config1 = {48000, 256, 32, 22, 18, 19, 20, false};

void process_audio(const int32_t* input, int32_t* output, size_t num_frames) {
    // Just copy the input to the output
    for (size_t i = 0; i < num_frames * 2; i++) {
        output[i] = input[i];
    }
    //Serial.println("Audio processing...");
}

void dma_i2s_in_handler0(void) {
    if (*(int32_t **)dma_hw->ch[i2s0.dma_ch_in_ctrl].read_addr == i2s0.input_buffer) {
        // it is inputting to the second buffer so we can overwrite the first
        process_audio(i2s0.input_buffer, i2s0.output_buffer, AUDIO_BUFFER_FRAMES);
    } else {
        // it is currently inputting the first buffer, so we write to the second
        process_audio(&i2s0.input_buffer[STEREO_BUFFER_SIZE], &i2s0.output_buffer[STEREO_BUFFER_SIZE], AUDIO_BUFFER_FRAMES);
    }
    dma_hw->ints0 = 1u << i2s0.dma_ch_in_data; // clear the IRQ
}

void dma_i2s_in_handler1(void) {
    if (*(int32_t **)dma_hw->ch[i2s1.dma_ch_in_ctrl].read_addr == i2s1.input_buffer) {
        // it is inputting to the second buffer so we can overwrite the first
        process_audio(i2s1.input_buffer, i2s1.output_buffer, AUDIO_BUFFER_FRAMES);
    } else {
        // it is currently inputting the first buffer, so we write to the second
        process_audio(&i2s1.input_buffer[STEREO_BUFFER_SIZE], &i2s1.output_buffer[STEREO_BUFFER_SIZE], AUDIO_BUFFER_FRAMES);
    }
    dma_hw->ints0 = 1u << i2s1.dma_ch_in_data; // clear the IRQ
}

void setup() {
    pinMode(LED_BUILTIN, OUTPUT);

    set_sys_clock_khz(132000, true);

    Serial.begin(9600);
    while(!Serial);

    i2s_program_start_slaved(pio0, &i2s_config0, dma_i2s_in_handler0, &i2s0);
    i2s_program_start_slaved(pio1, &i2s_config1, dma_i2s_in_handler1, &i2s1);
    //i2s_program_start_synched(pio0, &i2s_config0, dma_i2s_in_handler0, &i2s0);
    //i2s_program_start_synched(pio1, &i2s_config1, dma_i2s_in_handler1, &i2s1);

    Serial.println("Started double I2S example");
}

// the loop function runs over and over again forever
void loop() {
  // LED blink
  digitalWrite(LED_BUILTIN, HIGH);
  sleep_ms(250);
  digitalWrite(LED_BUILTIN, LOW);
  sleep_ms(250);
}

Therefore, I started debugging the code to find where the program execution was blocking. I ended up modifying the library, and I have a couple of questions on this:

1. In the entire library, the offset is always computed as offset = pio_add_program(pio0, &i2s_*_program) ; it is not clear to me why pio0 is used instead of the pio function parameter (i.e., pio0 or pio1 depending on the actual value of the parameter). I modified every offset calculation with offset = pio_add_program(pio, &i2s_*_program).
2. Once implemented 1), the next point where the program hangs is in the dma_double_buffer_init(). In the library, IRQ0 is always used to manage DMA interrupts. I modified the function as in the following, to use IRQ0 for pio0 and IRQ1 for pio1, and now the execution doesn't freeze anymore (in both synched and slaved mode).

static void dma_double_buffer_init(pio_i2s* i2s, void (*dma_handler)(void)) {

    // code here is unchanged

    if (i2s->pio == pio0) {
            // Input channel triggers the DMA interrupt handler, hopefully these stay
            // in perfect sync with the output.
            dma_channel_set_irq0_enabled(i2s->dma_ch_in_data, true);
            irq_set_exclusive_handler(DMA_IRQ_0, dma_handler);
            irq_set_enabled(DMA_IRQ_0, true);
        } else if (i2s->pio == pio1) {
            dma_channel_set_irq1_enabled(i2s->dma_ch_in_data, true);
            irq_set_exclusive_handler(DMA_IRQ_1, dma_handler);
            irq_set_enabled(DMA_IRQ_1, true);
        }

        // Enable all the dma channels
        dma_channel_start(i2s->dma_ch_out_ctrl);
        dma_channel_start(i2s->dma_ch_in_ctrl);
}

Now, in synched mode everything works fine. However, if I use slaved mode for both pio0 and pio1, the program is still not working correctly. Indeed, if I use a codec to generate the clock and a sine wave as input, I correctly see data output from the codec regarding bitclock, LRclock and data out but I do not see anything in output from the dataout pin of the RP2040.

I would really appreciate if you could give me some more clarifications and help me understand how to make things work properly.
Thank you!

[malacalypse]

Thanks for these good points.

First off, you should be able to use two PIO state-machine blocks on the same PIO unit (pio0 or pio1) since they share the code. There's no need to use pio0 and pio1 to do this, and I strongly suggest you don't do that. The blocks can run the same code independently using different data pins and shared inputs. The setup helpers don't do this for you, but it's not hard to do yourself. That would allow you to put everything on pio0.

1. I'll fix the pio0 hardcoded typo as soon as possible, nice catch.
2. Regarding DMA, I'm not sure there's a generic answer. If the codecs were running at different rates you'd want separate interrupts as they wouldn't have data ready or be needing a new buffer to transmit at the same time. However, in your case since they're synchronous, you really ideally want just one interrupt to fire when they're all ready. So the second DMA shouldn't set up an interrupt trigger at all, only transfer, and you use the trigger from the first DMA. You can't do that algorithmically, though, and I'm not sure hardcoding pio0 and pio1 to the respective IRQs is any better than it was because what if you want to use the DMA IRQ for another process, if you don't need it for the dual-I2S? And what if, as I discuss above, you run both I2S blocks on the same pio? This solution doesn't fit, so either way I think you'd need to customize the DMA init code for your case.

As for slaved mode, if you're not seeing the expected data on input, it's natural you won't see it on output! You'll have to see why your codec isn't sending you the data. Of course, since you're slaved, the codec needs to generate the clock signals (both BCK and LRCK, but MCK isn't needed or useful). Does it work with the original code and a single pio? Do you see the right clock signals on the expected clock input pins?

[alefais]

First off, you should be able to use two PIO state-machine blocks on the same PIO unit (pio0 or pio1) since they share the code. There's no need to use pio0 and pio1 to do this, and I strongly suggest you don't do that. The blocks can run the same code independently using different data pins and shared inputs. The setup helpers don't do this for you, but it's not hard to do yourself. That would allow you to put everything on pio0.

Thank you for the hint. From a theoretical point of view I see what you are suggesting, but I will need some time to dig deeper into the pio implementation and understand how to write the new helpers for my case. I was thinking of modifying the i2s_config struct to contain 2 data input and 2 data output pins, as well as the pio_i2s struct to contain different dma buffers for the two codecs. The new signature for the dma_double_buffer_init could be dma_double_buffer_init(pio_i2s* i2s0, pio_i2s* i2s1, void (*dma_handler)(void)). Here the two DMA buffers are set up and the interrupt is triggered once on IRQ0 (I get your point of using a single interrupt only since the codecs both run at 48kHz). The logic of the single dma_handler function will process audio coming from both codecs. Finally, the last part of the i2s_slave_program_init function must be done for the two SM of the same pio.
Is there something else I am missing out here? Also, the i2s_bidi_slave_program (which I am going to use) runs on a single SM? I was looking at the 12s.pio and the i2s_sck is the only program which needs more than one SM to run, correct?

As for the slaved mode, I can see the correct signals as outputs from the codec (BCK, LRCK and data out) but I do not see anything in output from the dataout pin of the RP2040.

[malacalypse]

I wouldn't worry so much about signatures of helpers as what the helpers are doing. These are broken up like this to make it modular and more clear what each part is doing and why it's there. If you put it all together it can get a little daunting to understand.

In general, from the PIO side, you need to load the code into the pio block memory, configure the individual sm GPIO (and the GPIO pins themselves, of course), then tell the state machines where to load their code from and what the wrap is, etc. as usual.

From the DMA side, you need to set up a pair of channels for the double buffering for each direction of each state machine. Read carefully through the DMA code to be sure you understand what it's doing - that's the magic behind it all in a way and I can't walk you through that here. Double-buffered DMA using chain pointers in the RP2040 is a lot trickier than doing it with classic circular-buffer DMA like in other MCUs, so you need to pay very careful attention to what the control channel is transferring and where, and what the dreq is for the main channel too.

==

I'm unclear as to whether you got the standard bidi slave with a single instance (the normal case for the code here) working as a slave yet with your codec, is that working or not? If not, there's a problem somewhere with either your codec or your handler code, because that's been confirmed to work by several other users here now (one of whom made a PR for it some time back).

Can you confirm clearly whether you've got at least the basic single-codec bi-directional slave case working for you?

Also, the i2s_bidi_slave_program (which I am going to use) runs on a single SM? I was looking at the 12s.pio and the i2s_sck is the only program which needs more than one SM to run, correct?

Yes, any of them run on a single SM. The SCK runs on a single SM too, by itself. What gave you the impression that it required more than one SM? (Asking because if there's something misleading I want to fix it.)

[alefais]

Thanks for the pointers, I will work on this!

Yes, the single-codec bi-directional slave program works correctly on a single pio. The problems I described above refer only to the case where two codecs (and two pio) are used. In this configuration, I used the codec to generate the clock and a sine wave as input and I can see that the BCK, LRCK and data signals are generated correctly by the codec. However, I can't see anything in output from the data_out pin of the pio that I am testing in the RP2040. This only happens when I use two pio.

Yes, any of them run on a single SM. The SCK runs on a single SM too, by itself. What gave you the impression that it required more than one SM?

I was misled by this example in 12s.pio line 32, but it is me who misinterpreted. Upon reading again now, it is clear that i2s_sck is executed on SM 0 only. I was initially under the impression that its execution required all three SM in the example.

; Use this as one state machine of the I2S PIO unit as a whole for perfect synchronization, e.g.:
; state machine 0 = clock (divide to 48000 * 256 * 2 = 24.576000 MHz for 48kHz stereo audio)
; state machine 1 = out (divide to 48000 * 64 * 2 = 6.144000 MHz for 48kHz stereo audio)
; state machine 2 = in (divide to 48000 * 256 * 2 = 24.576000 MHz for 48kHz stereo audio)

[malacalypse]

Ok, if you've got the basic variant working, then we've just got to work out the issues with duplicate SMs.

Thanks for clarifying the SCK SM thing. Glad to see it's not an error in the documentation.