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.
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.
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.
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.
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).
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.)
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