Example "MultipleBlinks" does not work (solved 2nd)

With Ardouno IDE 2.0.0 beta7: Compile and upload works.
According to the description, the multi-color LED should be switched on and off. As described, I entered '1' and '0', text is displayed, but the LED does nothing.

Please post the code so that we don't have to guess what you are referring to

Are you a robot? I cannot assess this answer otherwise!
Why should I copy here an example that can be reached in the IDE with 2 mouse clicks?

Have it your own way and do not make it as easy as possible to provide help

All of those examples build elf and not uf2 for me - so it's definitely not running for me.

WARNING: library Scheduler claims to run on mbed architecture(s) and may be incompatible with your current board which runs on mbed_nano architecture(s).
Sketch uses 79452 bytes (0%) of program storage space. Maximum is 16777216 bytes.
Global variables use 53348 bytes (19%) of dynamic memory, leaving 216988 bytes for local variables. Maximum is 270336 bytes.
/home/user/.arduino15/packages/arduino/tools/rp2040tools/1.0.2/rp2040load -v -D /tmp/arduino_build_210032/MultipleBlinks.ino.elf 

Not sure if you're having the same problem but they do not even load directly from the Arduino IDE for me.

Here's what I had to do to get MultipleBlinks to load.

  1. Export the binary through the UI
  2. Find elf2utf2 (mine was in ~/.arduino15/packages/arduino/tools/rp2040tools/1.0.2/elf2utf2)
  3. Run elf2utf2 against the exported binary
  4. Put the Connect in bootloader mode (hit the button twice)
  5. Copy the utf2 binary to the storage device

When it comes back online it still doesn't work. You can use the serial port to type '0' or '1' like the example says and you'll see "Led turned off!" but nothing happens with the RGB LED.

Edit: Nothing happens because those pins aren't defined in the pins.h for this board :upside_down_face:

Hello all.

Here's the sketch:


#include <Scheduler.h>

int led1 = LEDR;
int led2 = LEDG;
int led3 = LEDB;

void setup() {

  // Setup the 3 pins as OUTPUT
  pinMode(led1, OUTPUT);
  pinMode(led2, OUTPUT);
  pinMode(led3, OUTPUT);

  // Add "loop2" and "loop3" to scheduling.
  // "loop" is always started by default.

// Task no.1: blink LED with 1 second delay.
void loop() {
  digitalWrite(led1, HIGH);

  // When multiple tasks are running 'delay' passes control to
  // other tasks while waiting and guarantees they get executed.

  digitalWrite(led1, LOW);

// Task no.2: blink LED with 0.1 second delay.
void loop2() {
  digitalWrite(led2, HIGH);
  digitalWrite(led2, LOW);

// Task no.3: accept commands from Serial port
// '0' turns off LED
// '1' turns on LED
void loop3() {
  if (Serial.available()) {
    char c = Serial.read();
    if (c == '0') {
      digitalWrite(led3, LOW);
      Serial.println("Led turned off!");
    if (c == '1') {
      digitalWrite(led3, HIGH);
      Serial.println("Led turned on!");

  // We must call 'yield' at a regular basis to pass
  // control to other tasks.

Here's the fix:

In order to make this sketch work for the Nano RP2040 Connect, it's necessary to change these lines:

int led1 = LEDR;
int led2 = LEDG;
int led3 = LEDB;

to this:

#include <WiFiNINA.h>
NinaPin led1 = LEDR;
NinaPin led2 = LEDG;
NinaPin led3 = LEDB;

Why is the WiFiNINA library needed?

The Nano RP2040 Connect uses the u-blox NINA-W102 module for Wi-Fi connectivity. But this module is also just a standard ESP32 microcontroller. No reason to let those precious GPIO pins go to waste. So the RGB LED is connected to the NINA module, rather than taking up the RP2040 pins. So in order to blink these LEDs it's necessary for the RP2040 to communicate with the NINA module. That communication is handled by the WiFiNINA library.

This is described in the technical reference.

Why is the NinaPin type needed?

You can see that the NINA's pins are controlled by the familiar Arduino language pinMode() and digitalWrite()functions. But under the hood, this works quite differently when controlling these pins vs the RP2040's pins. The WiFiNINA library provides function overloads that use the NinaPin type for the pin number parameter instead of the usual PinName type:

There appears to be work in progress to improve on this situation with the Scheduler library:


To Pert: Thank you, this 4 lines where very helpful. I will remember your instructions at further experiments.

You're welcome. I'm glad if I was able to be of assistance.

Back with the inevitable (??) changes with Arduino - why?
This no longer works with nano_embed/2.2.0!
NanoPin has been changed to a class.
Why are working parts changed over and over again?

The change to a class was made in the pull request I linked to in my original reply. The description in that pull request provides an explanation for why the change was made:

Some sketches use a pattern like

int potpin = A5

Since NinaPin was an enum, the implicit cast was taking place, and any subsequent call to analogRead() would not use the Nina functions.