Mbed OS - New Features

Mbed OS
1

Let us know the features you would like to see in future releases of Mbed OS

3 Likes
3

I want a officially supported GUI, such as lvgl, qt, and so on.

3 Likes
4

Hereā€™s a list:

  • FOTA over BLE
  • more examples for just about everything in documentation
  • support for common peripherals like programmable led strips and IR.

As far as the last one goes, I bet lots of folks are relying on multi years old code from os.mbed.com/users

3 Likes
5

Support for using DMA in async SPI transactions for all MCUs that support it!

4 Likes
6

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.

9 Likes
7

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.

7 Likes
8

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
4 Likes
9

set_hostname() for EthernetInterface

10

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 - #4 by formula98

2 Likes
11

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.

2 Likes
12

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:

#if defined(DEVICE_COMPARATORIN)

#ifdef __cplusplus
extern "C" {
#endif

/** Comparator IRQ events
 */
typedef enum {
	COMP_IRQ_NONE,
	COMP_IRQ_UP,
	COMP_IRQ_DOWN,
} 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
}
#endif

#endif /* DEVICE_COMPARATORIN */
2 Likes
13

I2CSlave - Interrupt-driven would be really useful.

There are several ā€˜oldā€™ examples lying around, but some only work (if they work) with specific hardware.

14

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.

15

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
16

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
17
  • 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.

18

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

19

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.

20

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.