Arm Mbed OS support forum

Mbed OS - New Features

USBHost would be nice as well. There was already some USBHost support, but it was not included after the reorganisation of the USB support.

1 Like

Beast feature : Make MBED strustable.
Don’t break our old projects by deprecating essential and base classes (like you did with Serial and RawSerial) .
Keep at least one tool working either online or export.
Use github in the online IDE.
Stick to one tool and update it always. MBED tried different tools and none of them is working now correctly.
Don’t rush in adding new feature while current MBED is not stable and not bug-free.

1 Like
  • Support for the Raspberry Pi Pico microcontroller board, which is based on the RP2040 MCU containing two M0+ cores.
  • Support for dual-core or otherwise multicore MCUs

Currently, at least to my knowledge, when you compile and run Mbed on a multicore MCU (such as the STM32H7 family, which is supported) you upload to one core. You can upload to the other core but you have to compile a different project and upload it using another method.

I’m not a hardware guy - I use Mbed to implement IoT systems and perform ML experiments. However, if there’s any way I could help get this started, just point me to it and I’ll do my best to create a PR. Right now I have no idea where to start.

Unfortunately, this would likely take a massive redesign of the RTOS layer of Mbed. I studied it extensively when I created mbed-benchtest, and the RTX RTOS that it’s based on is fundamentally and completely a single core program. You would either need to completely rewrite it or swap it with another one (implementing the standard CMSIS RTOS API).

That makes sense. As long as the market as a whole does not move towards dual core microcontrollers, there is probably no incentive to undertake such a massive redesign.
Thank you for the clarification.
I would still like support for the Pico board, though - even if it’s just on one core.

1 Like

In some cases, the dual-core MCUs are not the same architecture variant, which could complicate things if Mbed-OS was built to run on multiple processors at once.

I don’t know of an embedded RTOS that supports multi-core with one copy of the program. The intended use of a separate core in many chips today is as a separate network processor (such as in the nRF5340). Many times, dual-core MCUs have boatloads of flash (and some even support XIP from external flash) so I don’t see this as a huge issue. The build/upload process might be a bit more painful, but there are ways to automate that.

The way I see this working in the near term is:

Introduce some new configuration options that are similar to the Managed Bootloader ones already available. This would allow you to specify a pre-built “dual-core-binary” that can then be merged with the current build artifacts in a post-build step. You would also have to specify the “dual-core-start-address” and possibly “dual-core-memory-size” so the tools could merge the programs into one hex file to be programmed.

Embedded Planet has provided a port of NXP’s Embedded Remote Procedure Call (erpc) library for Mbed-OS that could be used to facilitate inter-process-communication (IPC).

That would be a starting point to make multi-process applications with Mbed-OS.

Oh also, it may be necessary to port rpmsg-lite from NXP as well. erpc has a premade transport for this library but I haven’t used it.

We originally developed the erpc port for RPC over UART so we haven’t tested it for multi-process RPC.

That’s the next step I think, get erpc working on a multi-core Mbed target using rpmsg-lite.

Sorry for triple post, but ideas keep coming to me :slight_smile:

What would be really cool is some sort of abstraction that makes one able to use the EventQueue API to queue events that then run on the other processor :grin:

Not sure how feasible this is because, depending on the core architectures, it may not be possible (or allowed by an MPU) for one core to execute function pointers from another core’s memory region.

Perhaps we would need to come up with some C++ magic that lets us use ERPC to create a RPCCallback that is then mapped to a function on the coprocessor side. This RPCCallback could then be placed in an EventQueue-like structure to make multi-process programming on Mbed feel more familiar.

I don’t want to make a new post with nearly equal content. I just checked a little bit of the sources and often it confuses more than it enlightens.
Just as a simple example:
There is a DigitalInOut - but for what? There is no PinDirection InOut and there is no way to set a pin to in and out at the same time.
Then there are low level functions for which multiple wrappers with different names exist, instead of making function overloads with possibly optional parameters.
Next try to use RAII whenever possible (in cpp).
Last but not least the C++ objects are sometimes just wrappers around C functions without some OO background, e.g. I2C.

definitely make corresponding documentation:

there is wide mismatch between mbed classes shown in Online compiler:

and what is in webpage:

also some more easily understanding examples will helps a lot for not master level coders.

for example :
KVStore example

has one common 300line + example witch is difficult (for me) to understand.

But anyway. - Thanks for your time and great work on this project.

1 Like

Modbus RTU/ASCII/TCP would be usefull. There are some modbus library in the

1 Like

I would like Mbed to support DMA Drivers, modbus RTU/ASCII/TCP, and so on.

Dear sir,

Can support “Build Profile” in the mbed_app.json ?
For example:

"target_overrides": {
        "debug": {
       "release": {

Best Regards,

1 Like

I agree with @boraozgen. Better unit testing tools and documentation could be a great idea. A way of emulating Mbed OS devices/device in a Linux machine to run Mbed OS in docker would be highly appreciated too.

In addition, in my opinion it would be great to have a more modular design. For example, have options to completely disable network components or storage components to reduce compile times.

In addition, in my opinion it would be great to have a more modular design. For example, have options to completely disable network components or storage components to reduce compile times.

I agree. Fortunately, the design is already modular in some extent. At the present we can use the .mbedignore file for some sort of configuration (an example is available here). Nevertheless, it would be nice if we can include/exclude the modules using the mbed_app.json configuration file.

I am aware of .mbedignore importance, but in some cases it is really hard to isolate dependencies due to cross-dependencies between modules. I can’t remember the exact case, but I remember trying to remove high-level modules (such as TCP/IP connectivity) and adding other ones (such as storage) and it was nearly impossible because some modules depends on other which were excluded. I don’t know if you have had similar issues, but if you don’t believe me I can try to reproduce again…

Anyway, thank you for your point.

@MCU_Expresso you can already import your custom profile file.
Personally I have in my projects my mbed_app.json and custom_profile.json files.

But a documentation of the different parameters for the mbed_app.json file or for the build profile would be so much easier.

I wish that I could debug programs in the Mbed Studio on Mbed LPC1768 boards.

I wish there was also a Replied by criterion available in the forum’s Advanced Search.

This was already mentioned in a Tech Forum, but let me reiterate the request here:

Composite USB device support (e.g. CDC and HID, or CDC and MSC simultaneously)

1 Like