Arm Mbed OS support forum

Mbed OS on Raspberry Pi Pico anyone?

Seems that the recent launch of the new dual M0+ core Raspberry Pi Pico (RP2040) has everyone chattering on social media.

Is anyone within the mbed team wining and dining RPI org to get them to support Mbed OS on this little gem. This looks to be the better option than microPython, IMHO, especially for dual core ops.

6 Likes

I think it’s up to the Mbed OS developers to support it.
I have never worked on anything similar (I’m a data science guy) but I would be happy to help in some way if I can. I agree that the dual core design makes Mbed a great option for working with it.

usually, the support comes from the vendor of the controller, so support should come from Raspberry org. But Cortex-M seems to be a new product there, I fear there are no resources at the moment for Mbed support. Although I would appreciate it also.

I recall a blog post or something similar where they (RPi foundation) said that their team is small and they can’t allocate people to support various frameworks, such as Mbed.
I would imagine (although I’m not too familiar with the procedure and I’m not a hardware guy, so I might be completely wrong) that it’s not too difficult to add support for the board, since the datasheet and C/C++ SDK they provide will have all the defines.
If this is still not being worked on in two weeks when I’ll have some free time, I’ll give it a go.

Edit: It seems like the best solution for now is to create a custom board based on some similar target and change the pin defines, although I’m not sure if that would easily accommodate working with both cores.

The board looks very promising (dual core, compact …). I hope we can welcome it in the mbed ecosystem soon. By the way, I did an attempt to implement a limited scope of mbed API for Raspberry Pi. Since it was quite a long time ago it’s Mbed 2. But it can be used along with the native Raspberry Pi file system and threads.

Does MBED support symmetric dual core?

1 Like

Mbed appears to support dual core. Although it isn’t symmetric the STM32H747XIH6 is already Mbed enabled.

My understanding of the H7 is that you get to choose which core MBED runs on at compile time. If you want to use both cores you need to compile two MBED projects and load them into different addresses.

2 Likes

You are correct, Mbed does not support dual core, you need to compile two projects and flash them differently. At least this was the case 3 years and 2 months ago, based on this question. I haven’t seen any posts signifying that something has changed in that matter since then.

This then probably means it will be some time until the Pico is supported in all its dual core cababilities. I’d imagine that would require a significant amount of work to implement.

Then try to place, that Idea about multicore or RPi Pico, here - Mbed OS - New Features or Mbed OS Tech Forum - Live Stream - Mbed OS.
Maybe that will be fastest way you get a response at the moment.

BR, Jan

I note that the Arduino Portenta uses RPC (remote procedure call) method to transfer data (Arduino Code - not sure how this is translated to Mbed though).

Another dual core mbed enabled board would be PSoC6:PSoC 6 BLE Pioneer Kit | Mbed

Also here, I am not sure how mbed handles data transfer between PSoC M4/M0+ cores.

According to this reply I received on the “New Features” thread, it seems support for the dual core functionality isn’t coming soon, if ever.
Once the board is supported we will probably be able to run Mbed on one core.

Once it is supported, I will personally try to use Mbed on one core for all my RTOS functionality and manually put computationally intensive operations on the other core using the official SDK for the board/chip. I guess they provide mutexes and stuff so we’ll see how hard that would be.

Based on my experience using PSoC6 (although via PSoC Creator IDE) it too works off the principle of having to compile for each core, whereby you can instruct one core to remain in deep sleep throughout. You also define which core to handle the bootloader. Thus for mbed it would be nice to have a new CLI compile/link command which handles all this for you to make life easier to compile both cores.

I think my take on other platforms is that in all cases for application layer, the sync/async coordination and data transfer between cores is handled though software library (I believe PSoC Creator library uses shared memory addressed to exchange data too - in this case it would have to be a via the ext flash on the Pico, which is slower than RAM… or maybe you could use DMA somehow).

The question I’m putting forward is whether it’s worth the effort to create one mbed API library (as a core library) which could work for any platform (such as a RPC API library, for example with sync/async features) or whether it’s better just (or only viable) to develop libraries on platform by platform basis (i.e. one for Pico, one for PSoC, one for STM etc.)

Having two cores can also be useful in configuration when the other core is used as a “co-processor”, though. There is a very nice project

https://forums.mbed.com/t/marquesas-mbed-based-open-source-digital-gauge-cluster/

published by George Beckstein, running on STM32H745BI dual-core microcontroller:

The intent behind the dual-core MCU is that the M7 can run an application with all the UI code (way more surface area for potential bugs) while the M4 handles real-time functions like collecting data from other ECUs over the CAN bus, reading attached sensors, driving analog gauges, among other tasks. This makes it easier to harden the CM4 application handling all the critical functions of the gauge cluster.

A very feasible approach for me would be to make core0 to use full mbed and leave core 1 at sleep. The mechanisms to communicate and synchronize the cores at hardware should be implemented and also a function to load code for core1 and start it. Then core1 is useful for whatever you may consider maybe using the pico-SDK to be full bare metal.
I hope I get my first piece for testing soon!
BR
Walter

1 Like

Thanks for mentioning my gauge cluster project!

As I posted in the other thread (which you can read more in detail here), Embedded Planet has ported NXP’s Embedded RPC (erpc) library to Mbed-OS some time ago.

One of the intended use cases of this library is multicore systems

2 Likes

Looks like it is being worked on… :ok_hand: :+1:

1 Like

Thanks for mentioning my gauge cluster project!

Does this mean that we’ll soon be able to use JerryScript on the RP2040 to run javascript?

Maybe… if that does not work there is also this option to try out: GitHub - cesanta/mjs: Embedded JavaScript engine for C/C++