Arm Mbed OS support forum

Mbed OS - New Features

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
FATFileSystem
LittleFileSystem

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 code.mbed.com.

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,
Jason

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.

@davidAlonso:
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

Hi,

This is more for mbed studio, but I feel it needs mentioning:

Code Profiling, using gprof or other , is a needed feature IMHO.
RTOS task/thread profiling is another.

Thanks
Wayne

Well you can do this with existing Mbed if you make an ETM port on your PCB and have $2000 to drop on a J-Trace…

Well a poor man’s version can be done using SWO or SystemView/RTT :slight_smile:

I have already done some integration in Mbed/RTX to trace the task switches here: GitHub - Nantis-GmbH/mbed-systemview: Segger SystemView integration into Mbed OS

An official package manager support, such as Conan or Cargo, would be great too. This can be useful to distribute binaries and libraries instead of just source code.

2 Likes

I don’t want to make a new post with nearly equal content