Arm Mbed OS support forum

Mbed OS - New Features

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

2 Likes

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

3 Likes

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

1 Like

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

2 Likes

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.

6 Likes

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.

4 Likes

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
3 Likes

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

2 Likes

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

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 */
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