STM32-Arm Cortex

[AliFlamenco]

Moddable SDK doesn't support Arm Cortex-M4 and M3 like STM32F207 or LPC1768. I Think added this is usefull.

As Node-red-MCU uses Moddable sdk, added familiar MCU like LPC1768 or STM32F207 to it can be nice.

[AliFlamenco]

These days people prefer fast developing not writing codes in C/C++ specially in IOT systems that most of users don't have enough information and knowledge so languages like node-red. node-red-MCU is supporting ESP,nrf52,pico but large scale of familiar MCUs like LPC1768, STM32 is not supported.

[phoddie]

Thank you for the suggestion. Naturally, I completely agree that JavaScript is a great choice for IoT systems and many developers agree.

In fact, a developer working at a company did a port of our XS JavaScript engine to STM32 some time ago. Unfortunately, they did not publish that for others to use.

We would very much like to have an STM32 (or NXP) port of the Moddable SDK. Porting is a big project. There are two main challenges:

• Building our code using the platform tools.
• Integrating the various platform IO capabilities (Digital, I²C, Wi-Fi, etc)

Because these are large projects, we are limited in how many ports we can do. Of course, we are happy to work with the community to bring new ports to life.

[AliFlamenco]

Thanks for your response. I am a senior embedded programmer with 17 years experience. you are right. This project is too large and has many challenges but I think it is possible.
Maybe it is better to limit the project to minimum capabilities which are required in IOT (Serial port, Analog). some MCUs like STM32F207 does not have Wi-Fi or Bluetooth peripherals and they use serial port instead to communicate with a module like esp32. so serial port is more important and can be done firstly for example.

[AliFlamenco]

If developers in the company worked on this project before, how can discuss with them and continue their way.

[AliFlamenco]

@phoddie : dear peter, do you have any connection to developer team for STM32?

[AliFlamenco]

You are right. Of course, we may have to implement some APIs. But I think it is possible.
CMSIS RTOS is a vendor-independent hardware abstraction layer for the ARM Cortex-M processor series. So if we can run Moddable on these families, we will be able to expand to other families.
I have worked on STM32 with and without RTOS. I think it will work even on bare metal. But the existence of operating system would help more and is more reliable.

[phoddie]

CMSIS-RTOS is another viable target. I'm not very familiar with it, but it looks reasonably straightforward.

Some notes for comparison:

• FreeRTOS. We've long supported this, and it works well. However, FreeRTOS covers limited functionality - mostly related to tasks. There's no portability for GPIO or Serial code.
• Zephyr. At one point, a developer had the Moddable SDK running here. It worked well, and the code was solid. Zephyr has a much broader API surface, so GPIO and Serial are included, for example.
• CMSIS RTOS. Like Zephyr, this seems to have a large API surface. Unlike Zephyr, it seems mostly focused on ARM silicon (the API names begin with ARM_!) so the resulting port would work on fewer silicon targets.
• Bare metal. This is fun, the most compact, and generally the most challenging. For a high-volume product target, it could be a good approach. But, for a generally useful port of the Moddable SDK, it seems like the most work with the least re-use.

This is a very high-level overview. What important considerations does it overlook?

[AliFlamenco]

That was a good comparison. Of course for porting, wee need to work on low level too even we use best OS and APIs. This will be unavoidable.We need to prepare everything for the higher layers. We should also pay attention to the experiences available in the system and use them. As you said FreeRTOS is used in Moddable. So It can be a good choice even we have to make some low level APIs.
I think there should be steps to make this work possible. If you don't mind, I'll outline the first few steps:

• Identify available hardware (like Nucleo STM32F207ZG).
• Review the current OS (Free RTOS, RTX,...) and choose one according experiences and APIs.
• Study on cross-compilation environment and its connection to Moddable.
• Port basic XS runtime to selected board and configure IO to blink an LED.

What do you think?

[phoddie]

That all makes good sense. There's probably one step between "study" and "port" which is basically to integrate the build into mcconfig (the Moddable SDK build tool). That can be very easy or very difficult depending on the toolchain used by the target. Sometimes the build is more challenging than the runtime work.

Another step that we consider important is getting the our JavaScript debugger running. It can run over a serial/UART connection so it works with most silicon. While this isn't strictly necessary, it makes life much easier so we usually do that quite early.

Our current preference is to use Zephyr on ST silicon, at least to start. We have some experience there. We definitely have some customer requests for Zephyr. And Zephyr is supported on a wide variety of hardware. It may be some additional work, but it will also give us reach to more silicon targets more easily.

[AliFlamenco]

Thanks. Yes you are right.
We should figure out how to build and integrate the build into mcconfig. Of course this is the main part because when we can build the code and translate to MCU, flashing on MCU is not more important. By porting, I meant completing the translation, build, link, and final file creation steps.
About debugger, I think it is so important. In addition to our needs, users also have many needs. But I don't have any specific idea about when to implement it and how to do it. Your experiences can be helpful.
I am doing a review on FreeRTOS but according to your preference, I will do a review about Zephyr too.

In your opinion, how should the work begin, considering the steps mentioned?

[AliFlamenco]

Dear phoddie,
I tested ZephyrRTOS by running a simple program on the STM32F207. Overall, it’s a solid system, and the use of DeviceTree for hardware drivers (similar to Linux) is a smart design choice that makes extending to new hardware easier.

That said, I noticed a few challenges that might affect Moddable integration:

1. Installation complexity– Zephyr requires multiple dependencies. If Moddable runs on top of Zephyr, users will also need to install these, which could reduce the simplicity of the setup. Combining everything into a streamlined workflow may be challenging.

2. Hardware resource access*– Since JavaScript developers often have limited hardware knowledge, it would be better if hardware management is handled within Moddable and Zephyr, rather than left to the user.

3. Debugging – There are generally two approaches to debugging in these systems:

   • Real-time OS status reporting over a port such as serial (commonly used in FreeRTOS and Zephyr).
   • Low-level debugging with access to hardware registers via JTAG or SWD.
     For our purposes, I believe the first option would be more relevant.

I understand your time is very limited, and I truly appreciate the attention you’ve already given to this discussion. If possible, I would be glad to continue the conversation in a more direct way — even a short call or meeting — to summarize the key points and consider how we might practically start this project. Of course, I will adapt to whatever format or timing is most convenient for you.

[phoddie]

@AliFlamenco – Thank you for your excellent notes.

We've been exploring Zephyr a bit recently as well. I agree with your overall assessment. It is a professional, carefully designed system. The DeviceTree is convenient it that it gathers together many configuration details. On the flip side, it is designed to be used statically from C, which creates some additional work to use from a dynamic language like JavaScript. But, it seems possible.

On installation complexity, Zephyr is (very) big and complicated. That said, I've had good luck installing. It just takes time. In a perfect world, we would extend xs-dev to automate the set-up, just as it does for our other supported device targets.

On debugging, the Moddable SDK is about JavaScript so we need JavaScript debugging. That can run over serial (the same as we do on most microcontrollers). C developers can use JTAG / gdb / etc as usual on Zephyr – but that's out of scope for a Moddable SDK port.

We'd like to get a very basic Zephyr port working to to serve as a starting point for further exploration. If we were to do that, would you be willing to help try that out on different hardware and, perhaps, help implement some of the Zephyr specific modules?

[AliFlamenco]

@phoddie
Dear Peter,

Thank you again for your detailed responses and guidance regarding the Moddable SDK port on STM32. I am very interested in collaborating with you on this project and would like to discuss how we can practically start. I have a few questions to clarify:

When would you like to start this collaboration?

How should we initiate the work together?

What would be the exact starting point for the project?

What specific tasks or priorities should we focus on initially?

[phoddie]

@AliFlamenco – Excellent! We are thinking that we may have a starting point to share soon – a couple weeks. It would be a branch of the Moddable SDK. We did something similar for the Raspberry Pi Pico port a while back. There are a lot of areas of possible work on functionality – various IO, file system, networking, sensors, etc. That requires some knowledge of XS in C, our bridge between JavaScript and C. There's also many, many boards that support Zephyr. It would be valuable to try the port on a variety of those to see how truly portable it is.

[AliFlamenco]

@phoddie
Thank you for the exciting news about the upcoming branch — that’s really great to hear!
I’m very eager to contribute and help make the STM32/Zephyr port a success.

To make sure we move forward in an organized way, would you be open to putting together a simple roadmap and high-level architecture before we dive deep into coding?
I’d be glad to prepare an initial draft with the main areas we’ve discussed (build integration, XS runtime, basic IO modules, debugger support, etc.) so that we all have a clear picture of priorities and can coordinate contributions effectively.

Please let me know what you think, and if there’s a preferred format (document, call, or GitHub discussion) to start outlining the plan.

Thanks again for your support and guidance — I’m excited to get started!

[phoddie]

To make sure we move forward in an organized way, would you be open to putting together a simple roadmap and high-level architecture before we dive deep into coding?

Good idea. For Pico, we maintained a check-list as part of a GitHub discussion that allowed us to show the current status. That was easy and helpful.

We have some pieces working already, so we skip those in our plan. ;) I'll put together a list of what we intend to include in the initial push.

Please let me know what you think, and if there’s a preferred format (document, call, or GitHub discussion) to start outlining the plan.

Maybe a GitHub discussion is an easy place to start? We can expand to separate documents or even schedule a conference call if needed.

We should also talk about hardware. Zephyr runs on many boards. We cannot tackle them all at once. For our initial development, we have focused on ST using the Nucleo F413ZH board. These are reasonably capable (100 MHz Cortex M4, 320 KB RAM, 1.5 MB flash) and inexpensive ($20 USD). They don't have built-in networking, but one step at time. ;)

[phoddie]

Here's a quick summary of what we expect to have working in the branch:

• Moddable SDK build using west & CMake
• Firmware install
• Run
• XS JavaScript engine (most language features, including async/await)
• JavaScript debugging with xsbug over Zephyr serial IO
• ECMA-419 Digital and DigitalBank IO
• ECMA-419 I²C IO
• ECMA-419 Key-Value storage
• ECMA-419 Flash storage (partitions)
• Standard Web Worker (preemptive multitasking)
• Moddable SDK Timer module

Another good project would be getting the test support working on Zephyr so we can run unit tests using the test262 and testmc apps on Zephyr (as much as practical within the memory constraints of the target).

[AliFlamenco]

Dear Peter,

I’d like to share a quick update: I have successfully run Zephyr on STM32F207 and STM32G431. Unfortunately, STM32F413 boards are not available in my country, but I can continue with the boards I already have if that’s acceptable.

My perspective in taking on this collaboration is also to use it as part of my Master’s thesis. My goal is to make IoT development accessible for non-expert users. This path first led me to Node-RED, and from there I discovered the Moddable SDK, which I found very promising. At the same time, I would like this thesis to be a collaborative effort with you and Moddable, not just an individual project.

Therefore, I will need to approach the project systematically and eventually publish some academic results (e.g., a paper or a detailed report). To clarify expectations: do you see my role here mainly as an open-source contributor (similar to many others), or could it be structured more as a collaborative research effort with Moddable?

Either way, I’m eager to contribute, but this would help me understand how to balance the academic side with the open-source development.

Thanks again for your guidance and support — I’m very excited to continue!

[phoddie]

I have successfully run Zephyr on STM32F207 and STM32G431. Unfortunately, STM32F413 boards are not available...

That's fine. The STM32F207 looks similar enough. The STM32G431 has a bit more memory, which can only make things easier, especially early on.

My perspective in taking on this collaboration is also to use it as part of my Master’s thesis. My goal is to make IoT development accessible for non-expert users

Very nice. We share that goal.

To clarify expectations: do you see my role here mainly as an open-source contributor (similar to many others), or could it be structured more as a collaborative research effort with Moddable?

Our GitHub presence is about our open source work. Moddable is happy to discus how this can support your academic work. Please drop an email to our public address. We can continue that discussion there.

Specifically regarding Node-RED and non-expert users, you may want to look into the work by the team in Japan that wrote a book on Node-RED MCU Edition (and has been publishing supplements to it twice a year since).

[AliFlamenco]

Thanks for your attention.
I will be happy to colaborate and share this goal with moddable.
I sent an email to moddable public address you said.
Please continue discussion in that way you said.
Thanks verry much.