In the three years since we released Mbed OS 5, we’ve focused our engineering efforts on adding the feature set an IoT operating system requires. We’ve invested in connectivity, security, device management and storage. That investment has paid off. Mbed OS and Pelion Device Management now have most of the features required to develop, deploy and manage an IoT device.
In recent months, our engineering focus has shifted from feature development toward feature refinement and optimizations that will improve your developer experience. Many of these improvements come from direct engagement with Arm customers who are looking to deploy IoT devices at scale. The 5.14 release is the first of our regular Mbed OS releases throughout the coming months to include these improvements and optimizations.
When new developers begin using Mbed, one of the first issues they face is knowing which APIs are public and which are internal. As we’ve developed Mbed OS, the clear separation of public APIs from internal ones has diminished, and feedback we receive is that is confusing for developers. We’re pleased to say we’ve recognised this is something we should improve, and in 5.14, we’ve started to clearly delineate between public and internal APIs.
You can find out more from my colleague Evelyn Donnaes in her blog post here - https://os.mbed.com/blog/entry/Mbed-OS-directory-structure-and-public-h/
The use of printf statements as part of debug is well established, but the standard C library version brings in dependencies that increase the size of a debug image. For example, our simple Blinky example produces a 54KB image when you use the GCC compiler. We’ve developed an Mbed-specific version of printf, called minimal printf, which reduces the number of dependencies required and reduces the size of the compiled image to as low as 31KB using the same toolchain.
Secure element support
Feature development is continuing, and we’re pleased to add support for the Atmel AT608A secure element, the first of many secure elements to be supported in Mbed OS. As we explained as part of the Mbed OS 5.13 release blog, Arm’s Platform Security Architecture (PSA) initiative defines three platform configurations:
- V8-M with TrustZone (such as the NXP LPC55S69 or the Nuvoton M2351).
- Dual core v7-M (such as the Cypress PSoC6).
- Single core v7-M platform with a secure element, such as the Atmel SE.
A secure element provides a device manufacturer with a simple way of adding a hardware enclave where device identity, cryptographic keys, certificates and other credentials can be stored in a hardware isolated form that protects them from malicious attacks. This release of Mbed OS now provides software support for all three PSA configurations. We are working with other vendors to add support for their secure elements in future releases.
The Pelion IoT platform provides our customers with the ability to connect, manage and collate data at scale. In a landscape where the separation of the control and data planes is increasing, we’ve added official support for the Message Queueing Telemetry Transport (MQTT) protocol in a separate library that we will maintain and release alongside Mbed OS. MQTT is a publish- and subscribe-based messaging protocol that runs over TCP/IP and is widely used in transporting data from IoT devices to cloud-based services and applications.
For transport to the Pelion IoT platform, we mainly use the Lightweight Machine to Machine (LWM2M) protocol because it provides functionality suited to device management. However, MQTT is widely used for passing application data to cloud services and applications. With the release of Mbed OS 5.14, we now provide an officially supported implementation of MQTT.
You need to log in to post a discussion
Start new topic
26 Sep 2019
1 month, 1 week ago