Multicore use with Arduino IDE

[Bodmer]

There is a nice video tutorial here about using the two processor cores of the Raspberry Pi Pico. The tutorial uses the laborious process of using cmake etc, but with the Arduino IDE things are much easier so you can skip that bit!

The actual code example needed relatively few changes for the Arduino environment. Cut and paste the code below and you are up and running on two cores! See the video for how it works.

#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/multicore.h"
#include "hardware/irq.h"
#include "hardware/adc.h"


// Core 1 interrupt Handler
void core1_interrupt_handler() {
    // Receive Raw Value, Convert and Print Temperature Value
    while (multicore_fifo_rvalid()){
        uint32_t raw = multicore_fifo_pop_blocking();
        const float conversion_factor = 3.3f / (1 << 12);
        float result = raw * conversion_factor;
        float temp = 27 - (result - 0.706)/0.001721;
        Serial.printf("Temp = %f C\n", temp);        
    }

    multicore_fifo_clear_irq(); // Clear interrupt
}

// Core 1 Main Code
void core1_entry() {
    // Configure Core 1 Interrupt
    Serial.begin(115200);
    multicore_fifo_clear_irq();
    irq_set_exclusive_handler(SIO_IRQ_PROC1, core1_interrupt_handler);

    irq_set_enabled(SIO_IRQ_PROC1, true);

    // Infinite While Loop to wait for interrupt
    while (1){
        tight_loop_contents();
    }
}


// Core 0
void setup() {
    multicore_launch_core1(core1_entry); // Start core 1 - Do this before any interrupt configuration

    // Configure the ADC
    adc_init();
    adc_set_temp_sensor_enabled(true); // Enable on board temp sensor
    adc_select_input(4);
}

void loop() {
        uint32_t raw = adc_read();
        multicore_fifo_push_blocking(raw);
        sleep_ms(1000);
}

[earlephilhower]

Nice! Maybe use _wfi() in the core1 loop to save power, but that's the way to do it...

However, there is a gotcha here. If either core tries to update the flash (we now have a full-fledged filesystem and EEPROM), the whole board will crash hard.

To do this safely we need to add an interlock between both cores. Probably both listening to a high prio interrupt from the other and grabbing a mutex when they get there to be visible to the other core. Then all the flash routines need to assert that IRQ, wait for the other side to ack that they're in a safe RAM-located IRQ loop, do the flash work, then tell the other core it's free to continue.

Not rocket science, but not something I've had time to hack on. Biggest issue I see is avoiding any possible deadlock if both try to write to flash at the same time.

[Bodmer]

Got an error but it seems a double underscore is correct? Is this intended? __wfi()

[Bodmer]

Ah! Found it.
" The WFI (wait for interrupt) instruction waits for a interrupt to wake up the core. "

[mmadan2]

Hi @earlephilhower @Bodmer ,

I was trying to do something similar running 2 core together. But when I want to use the core 0 for writing Flash memory. I tried to use the lockout methods multicore_lockout_victim_init()(Called while launching code in Core 1) while launching my code on core 1 and when it's time to write to Flash I use multicore_lockout_start_blocking() (Called From Core 0) and after I am finish I use multicore_lockout_end_blocking(); (Called From Core 0). But even then the whole board crash hard.

I read the code in the both and they seems to be doing what @earlephilhower suggested to grab a mutex and then do the flash memory routine.

Any ideas If I am doing something wrong here.

[earlephilhower]

In this core you need to use the rp2040.idleOtherCore and rp2040.resumeOtherCore calls. Since I implemented the freeze function before the SDK did, it is not compatible with what they eventually added. Basically both use the intercore FIFO to cause an IRQ to the other core which then busywaits in a RAM code loop until a flag clears, but the details are not exactly the same. So calling the SDK function will not work as intended.

The important part is that busy wait in RAM loop. Just grabbing a mutex is not going to help because the other core won't be able to fetch code from flash while programming is going on (and hence crash).

[mmadan2]

Thanks for the reply @earlephilhower. I will give it a try and let you know how it goes.
just a small question can we use multicore_reset_core1(); and the start the core 1 again with

edit: I tried using the multicore_reset_core1(); and multicore_launch_core1(core1); this method does work for 2-5 time and then the whole board crashes again

[Bodmer]

Here is another multicore sketch tweaked for the Arduino environment, based on the simple example from here (with corrected typos!):

// Example for Arduino based on exmaple code here:
// https://raspberrypi.github.io/pico-sdk-doxygen/group__pico__multicore.html#multicore_example

#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/multicore.h"

#define FLAG_VALUE 123

void core1_entry() {

  multicore_fifo_push_blocking(FLAG_VALUE);

  uint32_t g = multicore_fifo_pop_blocking();

  if (g != FLAG_VALUE)
    Serial.printf("Hmm, that's not right on core 1!\n");
  else
    Serial.printf("It's all gone well on core 1!\n");

  while (1) __wfi();
}

void setup() {
  Serial.begin(115200);
  while (! Serial);
  delay(1000);

  Serial.printf("\nHello, multicore!\n");

  multicore_launch_core1(core1_entry);

  // Wait for it to start up

  uint32_t g = multicore_fifo_pop_blocking();

  if (g != FLAG_VALUE)
    Serial.printf("Hmm, that's not right on core 0!\n");
  else {
    multicore_fifo_push_blocking(FLAG_VALUE);
    Serial.printf("It's all gone well on core 0!\n");
  }
}


void loop() {
  // sleep as much as possible. Note: timer and serial port servicing interrupts will still keep the loop cycling.
  __wfi();
}

[earlephilhower]

Do you want to do a PR for these in the library/rp2040/examples directory as SDK multicore examples?

[rickygai]

hi Bodmer and earlephilhower,

I am new to Raspberry Pi Pico, I have tried the sketch, it looks to me like running under blocking mode ( eg. in TCP socket programming ).

Later, I modified the sketch like below and core1 is running with its while loop within simultaneously with the default loop() but I am unsure whether this is safe or not ?

#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/multicore.h"

const int LED_0 = LED_BUILTIN;
const int LED_1 = 28;
int cnt = 0;
int cnt_1 = 0;

void core1_entry() 
{
    Serial.printf( "\ncore1_entry()...ENTER" );

    while( 1 )
    {
    digitalWrite( LED_0, HIGH );
    delay( 256 );
    
    digitalWrite( LED_0, LOW );
    delay( 256 );

    Serial.printf( "\ncore_1...%i", cnt_1++ );

    tight_loop_contents();  // NOTE: if I replace this line with __wfi(), core1_entry() will not loop.
    };
        
    Serial.printf( "\ncore1_entry()...EXIT" );    
}

void setup() 
{
    Serial.begin( 115200 );
    while (! Serial);
    delay( 1000 );
    
    Serial.printf( "\nsetup()...ENTER -------------------------" );

    pinMode( LED_0, OUTPUT );
    pinMode( LED_1, OUTPUT );
      
    multicore_launch_core1( core1_entry );
       
    Serial.printf( "\nsetup()...EXIT -------------------------" );
}

void loop() 
{
    Serial.printf( "\n------------------------- loop() %i -------------------------", cnt );

    cnt++;

    digitalWrite( LED_1, HIGH );
    delay( 1000 );

    digitalWrite( LED_1, LOW );
    delay( 1000 );
    
    __wfi();
}

the result of serial monitor is as below:

QUESTIONS:

1. If I replaced the tight_loop_contents(); with __wfi() the while loop of the core1_entry() won't work, any reason ?

2. Is the core0 available ? I read the document at 2.8 Multi-core support, it mentioned _"the main application thread runs on core0", as ESP32 able to establish two core routines, instead of treating loop() as core0 in this case.

3. As I am not an expert in Raspberry Pi Pico, is the sketch I modified safe to use ?

4. Is there any Semaphore sample code available else where as sometime seeing the sample code is faster than reading the API documentation XD ?

Please advise.

Thank you.

Raspberry.Pi.Pico.-.Dual.Core.programming1.mp4

[Bodmer]

Hi, the blocking function simply waits for something to be available. There are functions that do not block as well, so in this later case the processor can do something else and come back later to try again.

To answer your questions:

1. __wfi is wait for interrupt. Since your modified code does not set up any interrupts it will wait forever.
2. The Arduino sketch runs on core 0, but your sketch can start core 1 running tasks.
3. I am not sure what "safe" means in this context. You will not damage your pico with your sketch.
4. Multicore programming has many pitfalls so it is best to read up about semaphores and mutexes.

Multicore programming is not usually explored much in the Arduino world due to the complexities and pitfalls, so is probably best avoided until programming skills have developed. Joining the Arduino forum would be a good idea as that is a great place to ask questions and get help.

[Bodmer]

A point of interest is that loop() does not freeze with __wfi, even though no interrupts have been set up by the sketch. The reason for this is that on core 0 the Arduino environment does run interrupts in the background to service timers and the serial port.

I think this code in the example I posted:

void loop() {
 __wfi();
}

may have led to confusion. The idea there was to make core 0 sleep in low power mode as much as possible, but the timers and serial stream will still get serviced. I have updated the sketch to clarify.

[rickygai]

Thanks Bodmer for the feedback, now understands better.

[Bodmer]

Your question about "is it safe to use" has different answers depending on whether you are looking at how it is used in a real system, whether it obeys hardware level rules/constraints , whether it may crash, or whether is it thread/concurrency safe.

A reasonable assumption is that the question was "is it thread safe". In this example it depends on what is considered to be the expected output. For example there is no management of which core can use the serial port. Although this does not cause either core to fall over and die, it does mean that characters in the messages output to the serial monitor window can get interleaved. For example you might get:

------co--re----_1------------- loop... etc

because each core may push characters into the print stream at the same instant. At the moment it appears to be "luck" that prevents this. Multicore programming without cordinating management via semaphores or mutexes is a bit like having two cooks in a kitchen that do not communicate. If one is making a meat pie, the other a fruit cake, and they both try to use the food mixer at the same time then neither cook will get what they expected!

[justinschoeman]

Hi all,

I have been playing with this so that I can have a separate GUI thread running on one core and a DSP thread running on the other.
But I have been getting strange issues. After much playing around, I discovered that something like:

void setup1(void) { if(!mutex_enter_timeout_ms(&setup_state_mutex, 10000UL)) die("SETUP_SHARED: Failed to get mutex!"); }

Would drop a block of zeros inside an array on the stack of the other setup() function.

What makes it extra strange is that the stacks definitely seem to be 0x1000 bytes apart, and none of the functions seem to involve any heap operations.

Does anybody have an idea where such corruption could come from?

[dsyleixa]

IMO that multithreading syntax from the TOP is far too complicated. Instead I would appreciate simple standard C/C++ pthread or std::thread API syntax what is already available on the ESP32 (a dual core too) for multiple, arbitrary numbers of parallel pre-emptive threads which can be assigned automatically or manually to either core. Here also e.g. mutexes are available and even thread prios.