How to use GPIOs?

[rei-vilo]

Now that Node-RED MCU is configured and running (see #26), I would like the blink the built-in LED of the Raspberry Pi Pico W.

How to address a GPIO? Which node should be used?

The GPIO-out section doesn't say much.

• On the Raspberry Pi Pico, built-in LED is GPIO25.
• On the Raspberry Pi Pico W, built-in LED is not managed directly, but by the WiFi CYW43439 radio WL_GPIO0.

Thank you!

[phoddie]

As you note, the Pico W doesn't connect the on-board LED directly to the MCU. Instead, it routes through the Wi-Fi part. To accommodate this hardware design, the Digital constructor supports that pin on GPIO bank 1. The LED is pin 0 of bank 1, so use 32 as the pin with the rpi-gpio out Node ((32 * 1) + 0). (I don't have a board with me to try, so this is based on reviewing the implementation!)

[rei-vilo]

Using pin 32 doesn't seem to work.

Neither other standard pins, like GPIO15.

[rei-vilo]

Thank you for the answer.

1. I am using Node-RED v3.0.2.
2. I have update the Moddable SDK.
3. I tried the revised GPIO blink flow.

Unfortunately, it raises an error:

sntp was not defined. call done.
/Users/USER/.node-red/node_modules/@ralphwetzel/node-red-mcu-plugin/mcu_modules/require/require.js (5) # Break: (host): module "child_process" not found!
XS abort: unhandled exception

To be continued...

[ralphwetzel]

Unfortunately, it raises an error:

I was already impressed how both of you were able to build this flow - as the plugin creates an erroneous manifest for rpi-gpio out (despite there's no need at all to create one! 😏 ). This is the error you hit here. A fix is on it's way...

[phoddie]

Thanks, @ralphwetzel. I had no idea where the "child_process" module was coming from. That's not a Moddable SDK or Node-RED MCU Edition module!

[ralphwetzel]

@phoddie --

We should see if @ralphwetzel can update the proxy and plug-in so that information is displayed to the user in the editor.

I thought about intercepting the message that the mcu sends to xsbug. Unfortunately this gives us only the error message - yet not the location of the error (== node id!). The best that can be done in this case is to display the message in the Console Monitor.

To get a behavior that mimics standard Node-RED demands to catch the error in the node, wrap "it" (error.message should be enough) in a trace container and send this to the editor:

    // Example: CompatibilityNode
    onMessage(msg, done) {
        try { 
            this.#events.input?.forEach(input => input.call(this, msg, this.#send, done));
        } catch(err) {
            trace.left(JSON.stringify({
                "error": {
                    "error": err.toString(),
                }
            }), node.id);
            // There should be a log / error message for xsbug as well...
        }
    }

This will create a standard error indication in Node-RED's Debug pane.

[phoddie]

Just FYI - I confirmed that the "rpi gpio" plugin allows several nodes to share a single GPIO, as long as they are all of the same type (input, output, PWM, etc). The MCU implementation now does the same, so that the flow @rei-vilo shared above (with two GPIO outputs connected to the same GPIO) now works without modification.

[rei-vilo]

Thank you so much for your help.

I can now turn the LED of the Raspberry Pi Pico W on and off through MQTT.

To be continued...