Pico Multicore Example - Blue Leader Only

[goingalong]

The multicore example under "arduino-pico/libraries/rp2040/examples/Multicore/" should output Red Leader and Blue Leader messages. I get Blue Leader only. This is similar to the problem with my own code where only one core seems to be assigned, so I was hoping that the example would give me a clue to where I am going wrong.

[earlephilhower]

You need the GIT version, not the release one, to get the multicore setup1()/loop1() to work. Maybe you're running the packaged version? I'll put a new package release once I finalize the multicore flash write protection, but it may be a little bit for that.

Also, just to be clear, you need to be running this version, not the one from Arduino.cc (it has "MBED" in the name IIRC). They do things differently and I think they didn't yet add support for everything in the RP2040.

[earlephilhower]

And one more thing. If you're getting the "Stay on target..." and 'Blue leader..." messages coming regularly, all is well. The USB serial port can take different amounts of time to start up, and the Arduino monitor can take different amounts of time to reconnect. So, you might miss the first 2 messages but from then on get the repeating bit. In that case, you can just increase the startup delay().

[goingalong]

Thank you for the quick reply. The version I am running is from here: https://github.com/earlephilhower/arduino-pico/tree/master/libraries/rp2040/examples/Multicore

All I get is repeats of "c0: Blue leader standing by ..."

// Demonstrates a simple use of the setup1()/loop1() functions
// for a multiprocessor run.

// Will output something like, where C0 is running on core 0 and
// C1 is on core 1, in parallel.

// 11:23:07.507 -> C0: Blue leader standing by...
// 11:23:07.507 -> C1: Red leader standing by...
// 11:23:07.507 -> C1: Stay on target...
// 11:23:08.008 -> C1: Stay on target...
// 11:23:08.505 -> C0: Blue leader standing by...
// 11:23:08.505 -> C1: Stay on target...
// 11:23:09.007 -> C1: Stay on target...
// 11:23:09.511 -> C0: Blue leader standing by...
// 11:23:09.511 -> C1: Stay on target...
// 11:23:10.015 -> C1: Stay on target...

// Released to the public domain

// The normal, core0 setup
void setup() {
  Serial.begin();
  delay(5000);
}

void loop() {
  Serial.printf("C0: Blue leader standing by...\n");
  delay(1000);
}

// Running on core1
void setup1() {
  delay(5000);
  Serial.printf("C1: Red leader standing by...\n");
}

void loop1() {
  Serial.printf("C1: Stay on target...\n");
  delay(500);
}

[goingalong]

Just re-read your answer. The board version I am running is not the Arduino MBED is is your version 1.1.0

[earlephilhower]

Well, that's not going to work. You will need to use a manual GIT clone as described in the readme until a new release is made.

[goingalong]

From the README I carried out the sequence in "Installing via GIT" but the step that tells the IDE where to look for the new board is not made clear and I am not a sufficiently expert Arduino IDE user to know how to fill in that blank. For now I will revert to single Core and wait for your new package release as and when. My thanks.

[Andy2No]

FWIW, I've now got Release 1.2.2 installed through the Arduino IDE boards manager (after dealing with problems caused by MalwareBytes), and ran this example on my Raspberry Pi Pico. Here's the output I get:

C0: Blue leader standing by...
C1: Stay on target...
C1: Stay on target...
C0: Blue leader standing by...
C1: Stay on target...
C1: Stay on target...
C0: Blue leader standing by...
C1: Stay on target...
C1: Stay on target...
C0: Blue leader standing by...
C1: Stay on target...
C1: Stay on target...
C0: Blue leader standing by...
C1: Stay on target...
C1: Stay on target...
C0: Blue leader standing by...

[earlephilhower]

That's the expected output, so I think you're good to go there!

[Andy2No]

Yep. I thought so. Thanks.

Maybe goingalong just needs the new version, then.

[Andy2No]

Here's an adaptation of that to make a multicore Blink, to generate a pseudo random pattern which won't repeat for quite a while.

This might help eliminate the Serial interface as a problem - it only uses the built in LED:

// Two cores fight over the state of one LED

// Demonstrates a simple use of the setup1()/loop1() functions
// for a multiprocessor run.

int led= LED_BUILTIN;
int led_off= 0;
int led_on= 1;

int off0= 231;
int on0= 307;
int off1= 513;
int on1= 707;

// The normal, core0 setup
void setup() {
  pinMode(led, OUTPUT); // Just do this on core0, not both
}

void loop() {
  delay(off0);
  digitalWrite(led, led_on);
  delay(on0);
  digitalWrite(led, led_off);
}

// Running on core1
void setup1() {
}

void loop1() {
  delay(off1);
  digitalWrite(led, led_on);
  delay(on1);
  digitalWrite(led, led_off);
}

[goingalong]

Thanks everyone. I reloaded from the Boards Manager which fetched 1.2.2. Then the adapted sketch from Andy2No runs ok.

The original version gives a serial port error. I gather you are aware of that but the error I get is pasted below anyway:

Global variables use 17056 bytes (6%) of dynamic memory, leaving 245088 bytes for local variables. Maximum is 262144 bytes.
Converting to uf2, output size: 440832, start address: 0x2000
Flashing /media/trevor/RPI-RP2 (RPI-RP2)
Wrote 440832 bytes to /media/trevor/RPI-RP2/NEW.UF2
processing.app.SerialException: Error opening serial port '1'.
	at processing.app.Serial.<init>(Serial.java:152)
	at processing.app.Serial.<init>(Serial.java:82)
	at processing.app.SerialMonitor$2.<init>(SerialMonitor.java:132)
	at processing.app.SerialMonitor.open(SerialMonitor.java:132)
	at processing.app.AbstractMonitor.resume(AbstractMonitor.java:132)
	at processing.app.Editor.resumeOrCloseSerialMonitor(Editor.java:2120)
	at processing.app.Editor.access$1300(Editor.java:117)
	at processing.app.Editor$UploadHandler.run(Editor.java:2089)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: jssc.SerialPortException: Port name - 1; Method name - openPort(); Exception type - Port not found.
	at jssc.SerialPort.openPort(SerialPort.java:167)
	at processing.app.Serial.<init>(Serial.java:141)
	... 8 more
Error opening serial port '1'.

[earlephilhower]

During the upload, there are often transient error messages like that. This is because the USB port is fully software controlled, and when going from the ROM-based update emulated flash drive to the sketch it takes some time. The emulated USB serial port may not come up immediately (or even if it does, the host OS may take a little bit to configure it), so the Serial Monitor dumps an error like that. On Windows and Linux, at least, the Serial Monitor automatically retries and it does reconnect just fine.

[goingalong]

OK, then all seems to be working.