MCU Builder node: Initial commit.

[ralphwetzel]

This is the initial attempt to support / automate the node-red-mcu building process.
This PR proposes a MCU builder node that is able to perform the building process from the node-red editor.
Minimal usecase:

The build parameters can either be provided as a parameter in msg.mcu or defined in the node config panel:

A short description of how to install this package was added to the readme.

No intensive testing has been performed ... thus: Expect the unexpected! 😉

[phoddie]

Interesting idea to integrate this as a node. I'm excited to try this out. After doing the npm install, I get this error launching Node-RED.

10 Jul 22:55:58 - [warn] [node-red-contrib-mcu/mcu] Error: Cannot find module 'fs-extra'
Require stack:
- /Users/hoddie/Downloads/node-red-mcu-main/mcu.js

Maybe it is just a dependency problelm?

[ralphwetzel]

I was unsure, if that was necessary - yet it seem to be (once):

cd <path to your cloned directory>
npm install

[phoddie]

That eliminates the error. I will try this out as soon as I can.

[phoddie]

I'm getting closer. ;)

When running the flow, I get this error:

11 Jul 12:16:44 - [error] [node-red-mcu:2226b30fe881e9d5] TypeError: Cannot read properties of undefined (reading 'flows')

Here' the flow set-up:

I created an empty directory for the working directory at node-red-mcu-test. Is that correct?

[ralphwetzel]

Sorry - I‘ve been a bit short yesterday describing the idea:

• First you create (at least) one flow that shall be built.
• Then you create another flow to setup the building process - utilizing the provided node. In its config you select the first flow & define the other parameters. This flow (in its easiest setup) looks like the one you‘re showing above.
• You have to deploy both flows.
• When you send a message into the MCU Builder node, it builds the selected (in this example == first) flow. Thus press the button of your inject node … and things should be performed.

I‘ll check if I can locate the issue you encountered…

[ralphwetzel]

I‘ll check if I can locate the issue you encountered…

Ok. I think I found the issue. As a workaround, please inject an empty object msg.mcu via the inject node. I‘ll provide a fix later this week.

[phoddie]

@ralphwetzel – that works! Very nice.

The "working directory" is where you create the Moddable SDK project.

I'm not sure what "Create Build Environment" does. I haven't had a chance to read your sources yet to understand what it does.

[ralphwetzel]

If you uncheck the option "Create Build Environment", only flows.js will be created (in the working directory) - yet the rest of the files not.
BTW: Feel free to propose a better wording for those labels - at best derived from the naming conventions used by XS.

[phoddie]

I really like your focus on trying to make things as easy as possible for users. I have a some suggestions for the configuration dialog with the goal of making it more accessible for casual users while maintaining access to more powerful capabilities for more advanced users.

For most users, it will be enough to just run the project. They don't need to know the path. Maybe it would be enough to create a temporary directory, put flows.js there, copy the necessary files, and build.

For more advanced users, an option to choose a path would be great. In that case, it could always just write write flows.js only.

The "build command line" is a bit esoteric for users getting started. For most users, it would be enough to choose either "simulator" (to run on thee local device) or give the platform ("esp32/moddable_two", "esp", "pico", etc). For device targets, you could provide boxes to enter Wi-Fi SSID and password and add those to the command line. An advanced option to provide the full command line would be a fallback for special cases.

[ralphwetzel]

As of now, the dialog matches the description you provided to build projects for XS. I agree, that it's currently quite technical - yet as well ultimately flexible. For the time being, I would like to focus on adding functionality ... knowing there's plentitude of opportunities to make things nicer.
That said, I propose to merge things as they are for now & put your valid comments on the ToDo-List.

[phoddie]

That's fine. I would prefer not to make the root of the node-red-mcu project specifically for the MCU builder. Maybe that is the right answer in the long term, but it seems too early to make that assumption. the nodes directory is for nodes that run on the MCU. What do you think about moving the content of this PR to tools/mcubuilder? It is pretty easy to imagine that there will be other tools eventually.

[ralphwetzel]

You're right. In the end, my proposal is just one way to integrate this idea into the NR editor. Thus I'll close this PR & keep things seperated - to not create too much interference.

[phoddie]

...my proposal is just one way to integrate this idea into the NR editor. Thus I'll close this PR & keep things separated - to not create too much interference

I still think it would be good to have as part of this repository. It is useful and provides an example for others who may with to explore other approaches.