The past 12 months for semiconductor IP firm ARM have been big. Really big. Let’s take a look at some of the highlights:
- The ARMv8-M architecture was introduced last November, bringing TrustZone-based hardware security to Cortex-M-class embedded and Internet of Things (IoT) devices
- This July, the company agreed to an acquisition by Japanese telco giant SoftBank for an estimated $32 billion
- In August, rival Intel announced it would license ARM physical IP to better position itself in the smartphone market
Not too bad for a year’s work. But if you’ve been paying close attention, something has been missing from ARM headlines since late 2014 – mbed.
The mbed schism
ARM originally launchedin 2009 as an online community and integrated development environment (IDE) for engineers working with Cortex-M microcontrollers (MCUs). This suite of tools evolved into what most developers know as mbed 2.0 or mbed “Classic.” However, with the IoT in full swing by 2014, the mbed platform had been reimagined as the mbed OS (or mbed 3.0), an end-to-end system stack that linked a client-side operating system (OS) with a server-side management platform called the mbed Device Server.
In theory, this was the right move. The goals of mbed 3.0 were to abstract the idiosyncrasies of embedded development on Cortex-M devices from multiple silicon vendors, while also providing higher level application developers with little to no expertise programming embedded devices access to the vast ecosystem of ARM-based hardware platforms.
In practice, though, it was not so simple. The introduction of a full-fledged OS, hypervisor, networking stacks, security, a web server, etc. in mbed 3.0 resulted in compatibility issues with mbed Classic as new tools and drivers were needed, and eventually the two versions split into separate codebases. Further, the OS developed in mbed 3.0 was an “event-driven OS,” meaning that instead of the multi-threaded operation and resource allocation indicative of traditional real-time operating system (RTOSs), the OS relied exclusively on peripheral interrupts so that it could remain in sleep mode as long as possible to conserve power. As any embedded programmer will tell you, the lack of RTOS functionality can present significant challenges when designing more complex or safety-critical systems, particularly when a developing systems that require certain stacks or file systems but not others. The result was a schism that more or less alienated that portion of the developer community.
Unifying IoT with mbed OS 5
Over the past year ARM’s mbed team has been working to merge mbed 2.0 and 3.0 into one cohesive ecosystem that bridges the gap between embedded developers and programmers working at the service layer. The result, announced in early August, is mbed 5 (mbed 2.0 + mbed 3.0 = mbed 5), a new rendition of the IoT platform that incorporates key features of its predecessors while also introducing capabilities that streamline mbed development (Figure 1):
- First and foremost, mbed OS 5 now includes a real-time kernel based on Keil’s RTX implementation of the CMSIS-RTOS. The RTOS core lies beneath the OS delivering native thread support to drivers and applications, and also integrates with networking stacks and mbed’s uVisor security kernel. The “Eventing OS” model has also been reinvented as a library, so users of the feature don’t lose any functionality.
- Second, in terms of tools, mbed OS 5 equips a command line interface (CLI) compatible with Windows, Mac OS X, and Linux environments that can be used for scripting, as well as support for the ARM Compiler 5, ARM GCC Embedded, and IAR compilers. The mbed Online Compiler is also now supported.
- Finally, the introduction of the RTOS and new tools has also enabled compatibility between mbed OS 5 and mbed Classic, resulting in a single, unified platform that serves the needs of both embedded and service-level developers.
The highlighted improvements are just a few of the updates included in mbed OS 5, which also incorporates new connectivity stacks and crypto libraries. The latest release, mbed OS 5.1, which is still free for developers, has currently been ported to 40 target platforms. According to sources at ARM, the mbed platform is now seeing 300,000 – 350,000 compiles per week.
mbed in use
provides device management and access provisioning tools and services for IoT customers on top of wireless connectivity modules based on Cortex-M-class processors, which it leverages due to their low power, cost, and wide availability. The company has long ported mbed to its devices as a means of abstracting away the challenges of managing vendor-specific processor variations, while also enabling them to focus on their core competency. The company is now seeing the mbed OS compiled upwards of 5,000 times per week across its products, one of which was the first deployable solution to support the mbed platform, says Daniel Quant, Vice President of Product Management and Strategic Marketing at MultiTech (Figure 2).
“What platform were we going to use at the edge? Were we going to develop our own platform, and how much resource would that have taken? How successful could we have been?” Quant says. “Most of the Cortex-Ms have had ARM mbed ported onto them, so it gives us a standard software platform on what is a very, very high running design across multiple manufacturers.
“We needed something that didn’t lock us into a vendor chain. mbed ticked those boxes,” he continues. “It’s now expanding. They’ve rethought what they were doing and made it more appealing to the embedded power user while also making it more appealing to programmers working at a service layer. mbed has given us the ability to put that together without having to reinvent the wheel ourselves.“
The trials of mbed are indicative of the IoT as a whole, with IT/OT integration revealing nuanced challenges in marrying two distinct technology segments. Additional announcements surrounding mbed are scheduled around ARM TechCon in November, which, hopefully, will help advance that unification.