Arm Mbed OS support forum

Mbed OS - New Features

I would prefer improved code, tooling and documentation quality over new features. I believe Mbed is already a feature-rich ecosystem, however reliability is more important for those who really want to build high-quality products. Furthermore there are many open GitHub issues to be dealt with.


I am not missing features in mbed OS right now. However quite often I find that examples that do not compile correctly or are using deprecated calls. Many examples and by forum users drivers on the forum are using old MBED os versions. It would be good if one could filter these upfront so when looking for code that can be reused as libraries you don’t spend ages finding it and then adapting it for new MBED OS versions.


Here is my “short” list (it isn’t short):

  • Audio driver frame work which includes: I2S and PDM microphones
  • True async and continuous ADC captures and DAC writing
  • DMA write output port values
  • SDIO HAL layer (for development of both block devices and SDIO based Wifi devices)
  • Protected or public method for getting the periperhal_obj_t* (for example, spi_t* type in the SPI HAL so that I can do things to the underlying device without losing all of the good higher level abstractions, but for most, if not all drivers. This is especially useful for peripherals that ARM does not intend to expand upon.
  • More driver APIs. I can really only speak for the ST products, but there are several GPIO-like peripherals that could be added with some effort. Just initially:
    • Comparator (GPIO like, but with two pins)
    • Touch controller
    • One-wire interface
    • Opamp control (possible as a takes an ADC in its contructor)
    • Debounce features on GPIO inputs
  • Additional features for some peripherals:
    • Second pin for PWM complementary output
    • Output settings for PWM:
      • one shot / finite shot
      • DMA streamed interface (example: every PWM cycle, update duty cycle with next value, or have updates update based on some pattern having an array that contains duty cycle in the upper half world and count to stay at that duty cycle in the lower half)
  • Features that make accessing certain memory areas easier (such as a small SRAM portion that has battery backup)
  • The BLE 5.2 audio profile

set_hostname() for EthernetInterface

Hi there wubaojun,

It’s not much, but I have a small framework for working with LVGL on Mbed OS here:

Contributions are always welcome! Also see a board I made to work with this here: Marquesas - Mbed-Based Open Source Digital Gauge Cluster


Hey there John,

I believe I mentioned this to you on GitHub, but for those who find this comment here and are interested in FOTA over BLE:

I ported mcuboot to mbed-os and finally got it merged recently (thanks to some help from ARM’s Lingkai Dong and Evelyne Donnaes!)

I have also been working with some of Mbed’s BLE team (Vincent Coubard and Paul Szczepanek) to expand the capabilities of Mbed BLE. We are currently working out of an experimental repository here.

One of the services I am currently working on there is a DFUService implementation. It’s a WIP, but you can find the PR and working specification here. Community input is welcome!

I have successfully performed firmware updates over BLE recently. I’m actively developing with the DFUService and will be committing my improvements as they are ready. I am planning to create a BLE DFU demo application in the near future.


I second all of these feature requests. A great list to work towards.

I find that the best way to get ARM to focus on a feature you want is to start the discussion yourself in the form of a PR on GitHub. Even a stubbed out API works and will get the community involved.

As a prompt: What does the HAL API for a comparator driver look like to you? What are “generic” features/functionality of a typical comparator MCU peripheral?

I invite you to write up a HAL header file for it and submit a PR on GitHub. I will surely review it, and I’m sure the community there will find additional ways to expand the proposed comparator HAL API! :slight_smile:

As a starting point, here’s what I came up with for a project a few years ago:


#ifdef __cplusplus
extern "C" {

/** Comparator IRQ events
typedef enum {
} comparator_irq_event;

/** Comparator IRQ HAL handler
typedef void (*comparator_irq_handler)(uint32_t id, comparator_irq_event event);

/** Comparator hal structure. */
typedef struct comp_s comp_t;

 * \defgroup hal_comparator Comparator hal functions
 * @{

/** Initialize the comparator peripheral
 * Configures the pin(s) used by the comparator.
 * @param obj The comparator object to initialize
 * @param pin_input The external input pin of the comparator
 * @param pin_reference The external reference input pin of the comparator (if used)
 * @param reference The internal reference to use for the comparator (if used)
 * @return -1 if configuration was invalid (external & internal references specified), 0 otherwise
int comparator_init(comp_t *obj, PinName pin_input,
		PinName pin_reference, float reference, uint32_t id);

/** Release the comparator object
 *@param obj The comparator object to release
void comparator_free(comp_t *obj);

/** Gets the status of the comparator
 * @param obj The comparator object
 * @return An integer value 1 or 0
int comparator_read(comp_t *obj);

/** Sets the hysteresis of the comparator
 * @param obj The comparator object
 * @param hysteresis The desired hysteresis
//void comparator_set_hysteresis(comp_t *obj, float hysteresis);

/** Enable/disable comparator IRQ
 * @param obj The comparator object
 * @param event The comparator IRQ event type
 * @param enable The enable flag
void comparator_irq_set(comp_t *obj, comparator_irq_event event, uint32_t enable);

/** Enable comparator IRQ
 * @param obj The comparator object
void comparator_irq_enable(comp_t *obj);

/** Disable comparator IRQ
 * @param obj The comparator object
void comparator_irq_disable(comp_t *obj);

/** Attach an IRQ function
 * @param obj The comparator object
 * @param function The IRQ handler function pointer
void comparator_irq_attach(comp_t *obj, comparator_irq_handler function);

#ifdef __cplusplus

1 Like

I2CSlave - Interrupt-driven would be really useful.

There are several ‘old’ examples lying around, but some only work (if they work) with specific hardware.

ADC channels - the current API is too limited, I believe a .read() initiates a conversion, the code then blocks until completion. It would be useful to be able to rapidly read the result of the latest conversion and to have a quick command to initiate a conversion, and either enable an interrupt on completion or at least provide a BUSY/READY flag. This to be workable over multiple channels please.

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