🛠 Exploiter les deux cœurs M0+ avec les FIFO inter-cœurs

Objectives

The RP2040 is symmetric: two identical Cortex-M0+ cores, a fully connected AHB crossbar, and most importantly, hardware inter-core FIFOs (32 × 32 bits in each direction) with dedicated interrupts. You will launch a task on core 1 (acquisition) and keep core 0 for output, exchanging data via blocking_fifo_push/pop — the producer/consumer pattern specific to the RP2040.

Hardware

• 1 × Raspberry Pi Pico + micro-USB data cable
• Pico SDK (CMake, gcc-arm-none-eabi); target to be linked with pico_multicore
• USB serial console at 115200 baud

Complete code

// multicore_fifo.c — core1 acquiert l'ADC, core0 affiche
#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/multicore.h"
#include "hardware/adc.h"

void core1_entry(void) {                    // tourne sur le cœur 1
    adc_init;
    adc_gpio_init(26);
    adc_select_input(0);
    while (true) {
        uint32_t sample = adc_read;       // 12 bits
        blocking_fifo_push(&fifo0_write_to_read, sample);
        sleep_ms(100);
    }
}

int main(void) {
    stdio_init_all;
    multicore_launch_core1(core1_entry);    // démarre le cœur 1
    while (true) {
        uint32_t sample = blocking_fifo_pop(&fifo1_write_to_read);
        printf("core0 recoit: %lu\n", sample);
    }
}

Expected verification

The console displays an ADC value every ~100 ms produced by the other core. Verify the symmetry: core 1 is started by multicore_launch_core1 from core 0, and both share the same 264 KB of RAM. Test blocking behavior: disconnect the potentiometer from GP26; the values remain consistent (floating) but nothing crashes — the FIFO acts as a buffer.

Common errors

• Using shared variables without protection instead of FIFOs: hardware FIFOs exist precisely to avoid locks on this bus.
• printf from both cores without stdio_set_assertion_enabled/mutex: interleaved output; centralize I/O on one core.
• Forgetting to link pico_multicore in target_link_libraries: multicore_launch_core1 not found at link time.
• Erasing flash (flash_safe_execute) from one core while the other executes XIP code: core 1 halts on a frozen bus — this is the documented XIP/flash pitfall; use the pico_flash library (SDK ≥ 1.5.1).
• sleep_ms on core1 before IRQs are handled: the SDK handles this, but it does not re-enable core 0's IRQs from core 1 without a proper multicore_reset_core1.