Arm E-mag 2016

2016 Volume 3 Number 1 embedded-computing.com/topics/processing

Tools of the Trade: Development Tools Powering the World’s Largest Processor Ecosystem Q&A with Javier Orensanz Martinez, Manager, Development Tools, ARM PLUS What's new with the mbed OS?

+

Sponsored by: ARM

E M A G

Featuring

Designing tools for the world’s number one ecosystem Q&A with Javier Orensanz Martinez, ARM

Securing the edge with ARM TrustZone for v8-M

By Abhijeet Rane, Sequitur Labs Inc .

Sub-threshold circuitry: Making Moore’s about power, not performance

By Brandon Lewis, Technology Editor

What’s new with the mbed OS?

By Brandon Lewis, Technology Editor

Sponsored By

© 2016 OpenSystems Media, © Embedded Computing Design. All registered brands and trademarks within the ARM E-mag are the property of their respective owners.

Designing tools for the world’s number one ecosystem Q&A with Javier Orensanz Martinez, ARM

Development tools are more critical than ever as ARM IP permeates real-time and safety-critical markets outside the consumer sector, such as industrial, medical, and transportation. In this Q&A, Javier Orensanz Martinez, GeneralManager of the Development Solutions Group at ARM, explains the evolving role of development tools such as DS-5 Development Studio, as well as how modeling technologies are allowing customers to bring solutions to market faster than ever before.

M sits at the heart of an incredibly diverse, R complex ecosystem. Can you describe some of the challenges tools vendors face in designing tools for a wide range of ecosystems as use cases for technologies expand?

A

ORENSANZ: Yes. You correctly point out that ARM technology is adopted in a large and growing number of software ecosystems with very different needs. For instance, the ways you develop applications for an Android phone, a Linux server, or a small connected device are very different. This is why it is so important that ARM has a wide ecosystem of tools providers to cater to those different 3

H

Today there are some trends in the software development space that are clear, such as the huge increase in software and system complexity, and growing concerns around security and safety.

ORENSANZ: There’s more process!

There will also be more emphasis on system testing and validation, so overall implementation costs increase. This is already well understood in automotive, but not in other embedded markets. You have to make sure that you have the right requirements and can guarantee that they have been met, ensuring this is all properly documented along the

nctional safety has become u a big topic of conversation in the technology industry.

Can you elaborate on the opportunities and challenges posed by safety markets such as automotive?

F

ORENSANZ: Safety considerations extend from automotive to any sort of transportation, industrial, robotics, and medical devices – to an extent anything that can damage humans or even other things – and in the future I expect that regulation will apply to all markets. This creates requirements in the way you develop products.

For example, we have code coverage tools that enable developers to demonstrate their code is properly validated. We also offer qualification kits that explain how to use the tools in a “safe manner” and document the validation and processes we’ve used to create our own tools. The focus on safety standards will drive more users towards professional development tools instead of free alternatives.

4

w is the growing importance o for safety and security changing the development cycle for developers?

use cases. We have tools for software development “close to the metal,” but rely on our partners for generic software development for niche industries.

Development Tools

way. For example, one requirement may be to achieve a certain level of performance, and your validation and production tests must be able to demonstrate that this will be the case in any situation. Demonstrating that your solution is secure is an even harder problem to solve.

cusing on security now, o with a growing ecosystem of devices and sensitive data could you discuss markets that require a high level of security and the associated challenges there?

F

ORENSANZ: The key markets are military, industrial, robotics, medical, and any transportation, including automotive, railways, avionics, and aerospace.

Unlike safety, which is quite established, security is a newer area.

Security has been a concern for PC operating systems (OSs) for a long time, and is now becoming a much greater focus in embedded industries. It could be your phone, car, or door lock – anything connected to the Internet needs to be designed with security in mind.

In regards to how this affects the design process, two elements are important.

Firstly, it’s the ability to update software online. As hackers come up with new ways of breaking into their targets, we will need to plug the security holes with new versions of the software for products in the field.

The second is that the industry needs development tools that specialize in security: for example, stress testing software that tries to find security holes in a product. Designing it right is not enough. You need to validate that the software is secure.

ere do you see ARM’s h tools sitting in the expanding ecosystem we’ve been discussing?

W

5

ORENSANZ: Our top priority is to enable the deployment of ARM IP to our silicon partners and key OEMs, which we fulfill with very early availability of our Fast Models, Cycle Models, and the DS-5 Development Studio.

In addition, we support the tools ecosystem by investing in the open-source GNU Compiler Collection (GCC) and Low-Level Virtual Machine (LLVM) compilers, creating standards such as the Cortex Microcontroller Software Interface Standard (CMSIS) standard and raising the bar in terms of product quality and features with mass market tools such as the Keil MDK. However, we still depend a lot on the ecosystem to cover a range of different options and price points, and to provide solutions for niche use cases.

ow is ARM able to guarantee early support for new IP?

H

ORENSANZ: Because of the development solutions group’s position within ARM we are integrated into the development cycle of new IP. For example, our compiler team is very involved in helping define new processor architectures as they need to ensure that the instruction set is compiler friendly. Or, for instance, when we create a new CPU the Fast Model is developed at 6

the same time so you can use the same validation tests on the model and the CPU itself.

Model-based methodologies are now fully embedded in the ARM IP design cycle and that of many of our silicon partners. Models are very important for us and the industry, and an area that we must cover because we are part of ARM. To give you an idea, we provided support for the ARMv8-A architecture in our tools and models two years before anyone else. We used these internally to port the UEFI bootcode, TrustZone firmware, Linux kernel, and Android to Architecture v8. We did all this work on models so by the time we had the first ARMv8-A silicon, we had an Android stack running on it in less than two weeks.

w do you see models o evolving to meet the needs of developers writing for real-time and/or safety applications?

H

ORENSANZ: Models already have some great advantages compared to hardware targets, particularly when you consider safety requirements. For instance, you can easily run and manage thousands of simulations in parallel with slightly different system settings, and replicate problems after you find

Development Tools

them. In addition, models, unlike most hardware, generate a perfect instruction trace that can be used for debug and code coverage.

tools in DS-5 that enable you to measure how efficiently the software runs on multicore targets and understand opportunities for improvement. That said, there is plenty of opportunity to do more in this Models also have great potential to do area, particularly when you connect softfault injection and help with other types ware, models, and tools. of stress testing, although this is not something that we support today. ow do you think that ARM’s

H

acquisition by SoftBank will impact ARM’s development tools?

In regards to challenges, the key one is complexity: as systems and software grow in complexity, we also need to increase the speed of the simulation. This ORENSANZ: ARM is now part of the is a priority for us at the moment.

SoftBank Group, and the vision and mission will not change; it is business as usual o you feel that software is – only better. Everyone at ARM is feeling taking advantage of the very positive about the future, which growing number of processors holds many opportunities for growth in embedded systems? both for us and our tools partners, particularly in new areas such as servers, enterORENSANZ: Most software will not prise, and IoT. increase its performance linearly with the number of processors in a system, Javier Orensanz Martinez is General as there are communication costs Manager of the Development Solutions between different processors and Group at ARM. chips. In addition, the software is often not optimized for a particular target Learn more about ARM’s development because of practical reasons, such as tools: running the same game on multiple phone models.  developer.arm.com

D

ARM and its ecosystem are investing a lot in this area. For example, there has been some great innovation in the new Linux Energy-Aware Scheduler (EAS). In addition, we provide performance analysis

 @ARMEmbedded  www.linkedin.com/company/ARM  www.facebook.com/ARMfans 7

Securing the edge with ARM TrustZone for v8-M

By Abhijeet Rane, Sequitur Labs Inc.

ARM’s new 32-bit ARMv8-M architecture was introduced in 2015, adding TrustZone security extensions for Cortex-M microcontrollers (MCUs), among other features. As v8-M-based silicon comes to market, it’s essential that developers understand the architecture, the new capabilities it offers, and how to implement it in the design of connected edge devices that form the foundation of secure end-to-end systems.

Internet of Things (IoT) security issues often result from inadequate protection for devices at the edge of a connected system.

These tend to be low power, cheap m i c ro c o n t ro l ler-based devices that perform a single function, like temperature monitoring. Lack of processing power, memory, and, of course, cost, are often cited as reasons for not being able to properly secure these assets, which are increasingly being exploited by hackers as trampolines to higher value assets 8

connected to the same network. In order to protect intellectual property, customer data, user safety, and brand reputation against such threats, device makers have investigated a variety of techniques to secure vulnerable endpoints, including the use of multiple MCUs with one or more dedicated solely to performing security functions such as encryption and authentication. This of course raises complexity and cost, and adds another line item to a bill of materials (BOM).

TrustZone for ARMv8-M

Fortunately, however, that is set to change for MCU-based devices. In 2015 ARM announced that its hardware-based security technology, TrustZone, would be available on Cortex-M MCUs by virtue of the new v8-M architecture. With security capabilities akin to what has been widely deployed across Cortex-A application procesors, ARMv8-M brings foundational security to Cortex-M devices and enables the creation of IoT systems that are secure from end to end.

TrustZone extensions for ARMv8-M: Enhanced security architecture The ARMv8-M architecture is a 32-bit architecture that maintains compatibility with ARMv6-M and ARMv7-M to ease software migration within the Cortex-M family, while also incorporating a host of enhancements and new capabilities, most notably in the way of security. The security enhancements include improvements to the Protected Memory System Architecture and the aforementioned inclusion of TrustZone security extensions, the latter of which allows secure and non-secure states to be established so that multiple security domains can exist within a single Cortex-M device.

System on chips (SoCs) often include multiple microprocessors, each assigned to offload system management or other tasks (I/O for example).

In this architecture, one processor typically operates in a privileged state and the other in non-privileged state.

While MCU-based systems have also had the ability to establish privileged and unprivileged states via the use of memory protection units (MPUs) or memory management units (MMUs) for some time, the v8-M TrustZone extensions provide an additional level of security and more efficient resource utilization, which reduces system design complexity and thereby cost.

How it works Conceptually, TrustZone for v8-M works similar to TrustZone for Cortex-A processors. Unlike TrustZone technology for Cortex-A-class processors, however, there is no Secure Monitor to manage transitions between the two states.

Instead, the secure and non-secure states are memory map based, which eliminates switching overhead and effectively fulfills the energy efficiency requirements of edge devices (Figure 1).

With TrustZone extensions for v8-M, the definition of secure and non-secure regions in an MCU is at the discretion of the chip designer. This is done using a new capability called the Secure Attribution Unit (SAU), a software technology that is used to define secure and non-secure memory regions. Alternatively, device- or system-specific controller logic tied to a special Implementation Defined 9

Attribution Unit (IDAU) interface to the processor can be used accomplish the same. The key difference between the two is that the SAU is programmable in secure states, whereas the IDAU creates a fixed memory map.

TrustZone for ARMv8-A NON-SECURE STATES

Rich OS, e.g. Linux

SECURE STATES

NON-SECURE STATES

SECURE STATES

Secure App/Libs

Nonsecure App

Secure App/Libs

Secure OS

Nonsecure OS

Secure OS

Secure Monitor

TrustZone for ARMv8-M

Figure 1 | TrustZone extensions for ARMv8-M removes the Secure Monitor for more efficient switching between secure and non-secure states in resource-constrained Cortex-M processors.

The processor state depends on which memory region (secure or non-secure) is accessed. The processor state is secure if code is running in the secure memory region, and, similar to traditional TrustZone technology, code executing in the secure memory region has access to the non-secure region but not the other way around. However, TrustZone for v8-M introduces an additional memory type within the secure region called a Non-secure Callable (NSC) that acts as an entry point for code running in the non-secure memory region to access services, functions, or data in the secure region. Thus, the NSC portion of memory adds a degree of separation between secure and non-secure memory regions while facilitating access to secure functions. Application developers who need to use NSC memory must do so using a new instruction introduced in the v8 10

TrustZone for ARMv8-M

architecture called the Secure Gateway (SG). The SG instruction must reside in NSC memory and must be the first instruction in the API to access secure functions. Any attempt to access secure memory without a valid SG instruction leads to a hard fault.

In addition, ARM has also enhanced AHB-Lite that was defined as part of the AMBA 3.0 interconnect specification. Now AMBA 5 AHB5, the updated specification adds a special instruction to flag secure and non-secure bus transactions, permitting systems with TrustZone for ARM v8-M to interoperate with TrustZone on Cortex-A devices.

This feature is essential for enablement design scalability and end-to-end, system-wide security.

Edge protection scenarios There are a number of security applications

TrustZone for ARMv8-M

enabled by the new TrustZone extensions for ARMv8-M, including:

õõ

õõ

õõ

õõ

õõ

IP protection: Intellectual property, such as proprietary algorithms, relate directly to a company’s intrinsic value.

Device makers can use TrustZone for ARMv8-M to store intellectual property in secure memory while still allowing non-secure applications to access it via APIs. Secure storage of critical information: Keeping user data, identity information, and security keys separate from the rest of the system ensures confidentiality.

Root of trust implementation: A root of trust implementation provides a secure foundation for many different applications, such as secure overthe-air (OTA) firmware updates.

Such a basis of trust is also critical to enabling mutual authentication between devices in a system.

Sandboxing of certified software: Software certification is an expensive process. Using certified software for cryptography, for example, allows device makers to enter new markets where such requirements are mandated. TrustZone for ARMv8-M allows keeping such code in secure memory regions while allowing access to applications via APIs in NSC memory regions.

Reducing cost via processor consolidation: In complex SoCs

where one processor may be dedicated to performing security functions, TrustZone for ARMv8-M makes it possible to implement the same security capabilities as would be performed by the dedicated processor, thereby reducing cost and complexity.

End-to-end security example Let’s take a simple door lock example to demonstrate the usefulness of TrustZone for ARM v8-M in achieving end-to-end security. There are four parts to this system – a door lock, a Cortex-M MCU based camera unit with TrustZone extensions for ARMv8-M that controls the lock, a Cortex-A microprocessor-based gateway with TrustZone technology, and a smartphone. When someone comes to the door, the camera takes an image and sends it to the gateway, which relays the image to a mobile phone app. Upon viewing the image, the user clicks a button in the app to open the door.

In this example, the edge node gains its root of trust from TrustZone for ARMv8-M, which becomes the basis for authenticating itself to the gateway.

The gateway also authenticates itself to the mobile phone via TrustZone on the Cortex-A MPU. When the user selects the “open door” command on their phone, the phone relays it to the gateway, which in turn relays it to the edge node to open the door. Commands relayed 11

between devices are validated at each step as part of the process, ensuring system-wide integrity (Figure 2).

Tr u s t Z o n e for ARMv8-M supports energy-conscious devices like wearables or battery-operated edge nodes in markets such as smart utilities and smart cities. Not Figure 2 | TrustZone extensions for ARMv8-M enable the creation of secure IoT systems with integrity validated at each level of the design. only do the TrustZone extensions make it possible to secure the edge, but they result in short-term learning curves that change security economics by reducing could impact the development process. complexity and eliminating additional But weighed against the cost of releasing parts dedicated to performing security insecure products, the decision is a functions. While TrustZone for ARMv8-M- simple one – TrustZone for ARMv8-M fills capable silicon has yet to hit the market, an immediate gap in the path towards several software companies – including system-wide security for the IoT. Express Logic, Green Hills Software, IAR Systems, IBM, Mentor Graphics, Micrium, Abhijeet Rane is Vice President of Real-Time Engineers, Symantec, and Marketing at Sequitur Labs Inc. Trustonic – have announced their intentions to support it.

Sequitur Labs Inc. Ultimately, the choice to leverage the  www.sequiturlabs.com capabilities of ARMv8-M lies with device makers, as TrustZone for v8-M will @SequiturLabs require that developers change application development practices. Using www.linkedin.com/ TrustZone for ARMv8-M enforces discicompany/3567007 plined thinking about what information needs to be protected, and will likely www.facebook.com/sequiturlabs

  

12

Sub-threshold circuitry: Making Moore’s about power, not performance

By Brandon Lewis, Technology Editor

As silicon geometries approach the edge of physics, a new rule of thumb is poised to govern the computing industry: “Thou shalt reduce power consumption by 50 percent every two years.” How could that be possible? Subthreshold voltage circuitry.

The ULPBench is a standardized benchmark developed by the Embedded Microprocessor Benchmark Consortium (EEMBC) for measuring the energy efficiency of ultra-low power (ULP) embedded microcontrollers (MCUs). The benchmark ports a normalized set of MCU workloads to a target, such as memory and math operations, sorting, and GPIO interaction. These workloads form the basis for analyzing the active and low-power conditions of 8-, 16-, or 32-bit MCUs, including active current, sleep current, core efficiency, cache efficiency, and wake-up time. The results are then calculated using a reciprocal formula (1000/

Median of 5 times average energy per second for 10 ULPBench cycles), yielding a score based on the amount of energy consumed during workload operation – the ULPBench.

13

In November 2015, Ambiq Micro (www. ambiqmicro.com), a semiconductor vendor out of Austin, TX, submitted its Apollo MCU for testing against the ULPBench, scoring 377.50 (the reciprocal formula means the higher the benchmark score, the better), more than twice that of the previous bellwether, STMicroelectronics’ STM32L476RG. Depending on the direction of an application, this 2x power savings can be repurposed to extend battery life or add new features (Sidebar 1). According to

Scott Hanson, Ph.D., Founder and CTO of Ambiq Micro, advances in energy efficiency such as those being realized today could lead to a new iteration of Moore’s law in which the power consumption of embedded microprocessors is cut in half every couple of years.

“What we’re seeing is every one of our customers wants to one-up their product from last year,” Hanson says. “If they want to add some great new feature – maybe last year it was heart rate monitoring

Sidebar 1

Wearable energy efficiency beyond the battery

By Jamie Leland, Content Assistant It’s true: charging a Fitbit couldn’t be simpler. Still, for a wearable device, especially one that requires 24-hour wear to take full advantage of its capabilities, charging even once a week feels like a chore. When the battery drains, it’s like your carriage turned back into a pumpkin. What was once the leading authority on your personal fitness level is now just an ugly, slightly uncomfortable bracelet. It’s so disenchanting that every time you put it on the charger, it might not make it back onto your wrist.

This is exactly the problem that Misfit wanted to remedy. Their goal? Produce a device that never needs to be removed.

The result? Their original tracker, the Misfit Shine, boasted a six-month battery life; most activity trackers need to be charged at least once a week.

But while the Shine outpaced most other trackers in battery life, many users found the functionality to be too limited. The Shine was equipped with a Silicon Labs EFM32 MCU, Bluetooth Low Energy (BLE), and a 3-axis accelerometer. That put the Shine about on par with Fitbit’s most basic offering, the Fitbit Zip, which, while not intended to track sleep, offers similar battery life and a more useful display. The next-generation Shine would need to add functionality without backpedaling on their commitment to long-term wear.

14

Ultra-Low Power on Cortex-M4

and this year a microphone to do some always-on voice processing – that all takes CPU cycles. Today a lot of these companies are only running effectively at 1 million instructions per second (MIPS) or so, so very few cycles per second.

Maybe they want to make a leap to 10 MIPS and, suddenly, MCU power goes from being a 25 percent contributor to a 75 percent contributor. That’s a problem.

same area, we have to be very focused on driving energy down 2x or 4x every single year,” he adds.

Sub-threshold voltage circuitry demystified

What enables the Apollo MCU to achieve such notable ULP performance metrics is the use of sub-threshold circuitry, which operates on supply voltages below the threshold voltage of typical 1.8V or 3.3V MCUs. Threshold voltage represents “Much in the same way that Moore’s law the minimum gate-to-source voltage was about adding more transistors in the

Enter Ambiq Micro’s Apollo MCU. The Apollo in the Misfit Shine 2, twice as powerful as the EFM32 MCU in the original Shine, allowed for the addition of a vibration motor for call and text notifications; multicolored LEDs and a capacitive touch sensor for a more clear, interactive user interface; and a magnetometer to improve the accuracy of activity tracking. Thanks to Ambiq’s SPOT platform, the Apollo also boasts industry-leading energy efficiency, mitigating tradeoffs in power consumption brought on by the added functionality to retain the six-month battery life of the Shine 2’s predecessor.

But while the Apollo offers unparalleled power consumption compared to similar MCUs, the processor isn’t the only place where battery life can be extended. Other components, such as sensors and wireless chips, could also leverage sub-threshold circuitry such as that used on the Apollo MCU to reduce power, and software can be optimized to further increase energy efficiency.

The way Ambiq’s Chief Technology Officer Scott Hanson sees it, “We’re constantly going to be talking about how we need to be lower energy and the batteries need to be better. Every component needs to be more efficient than it is today. We’re always going to be under that pressure.”

Figure 1 | The Misfit Shine 2 has a six-month battery life.

Similar activity trackers, like Fitbit’s newest and most advanced “everyday” offering the Fitbit Alta, require a charge about every five days.

15

these state changes, which directly correlates with power consumption as dynamic energy – the energy associated with turning transistors on or off – is calculated by squaring the operating voltage (Figures 1 and 2).

Ambiq, however, uses their Sub-threshold Power Optimized Technology, or Figure 1 | A typical 1.8V IC requires a significant amount of current to achieve a state change.

SPOT, to operate transistors at voltages of less than 0.5V (sub-threshold), which provides a couple of benefits (Figure 3). First, state switching at these lower operating voltages makes for lower dynamic energy consumption; Second, the leakage current (see Figure 2) of “off” transistors can be harnessed to perform most computations, in essence recapturing previously lost power. In the case of Ambiq’s 32-bit Figure 2 | Dynamic power consumption, or the energy required to ARM Cortex-M4F-based switch a transistor on or off, is responsible for the majority of the Apollo MCUs running at up energy used by ICs, particularly at higher operating voltages. to 24 MHz, the result is a required to change a transistor’s state platform that consumes 34 µA/MHz exefrom “off” to “on” or drive a signal “low” cuting from flash and sleep currents as or “high” for logic purposes. In a stan- low as 140 nA, both of which are lower dard 1.8V integrated circuit (IC), signifi- than competitive Cortex-M0+ offerings, cant current can be required to perform the company says.

16

Ultra-Low Power on Cortex-M4

“What we effectively do is we take a normal microprocessor, including both the analog elements and the digital elements, and run them at much lower voltage,” Hanson explains. “On the digital side we dial down the voltage very low, anywhere between 200 mV and 600 mV, depending on the type Figure 3 | Ambiq’s SPOT platform operates transistors at sub-threshold of device you’re using. voltages of less than 0.5V to achieve significant energy savings compared That requires a systo standard IC implementations. tem-wide change in how you design the chip, from the standard cells to how you do simulations to how you do time enclosure to how you do voltage regulation – all of that has to be modified specifically to run at lower voltage.

And then on the analog side we run at extremely low gate-tosource voltages, so we’ll use tail currents in amplifiers that are as low as a few picoamps.”

Figure 4 | Besides exponential current fluctuations in response to changes in operating voltages at sub-threshold levels, slight temperature variations can lead to radical current deltas as well.

This mandates significant compensation in sub-threshold circuitry.

Sub-threshold circuitry is not without its challenges, however. While it can deliver exponential gains in energy efficiency, such low-voltage operation precludes processor speeds above a couple hundred MHz (for now) and also makes for circuits that are inherently more sensitive

to fluctuations in temperature and voltage (Figure 4).

“This obviously comes with its share of problems,” Hanson says. “We’re very 17

sensitive to temperature fluctuations and voltage fluctuations and process fluctuations, but we have a pretty wide range of techniques that we use to address that, for instance with proprietary analog circuit building blocks. Every analog circuit that you can read about in a textbook is based on saturated transistors and bipolar transistors, not sub-thresholdbased MOSFETS, so we have had to reinvent a lot of the underlying analog circuit building blocks such that they work at extremely low sub-threshold currents.

“Internally, we’re doing a lot of voltage conversion to get voltage down, we’re managing all the process variations, voltage variations, and temperature variations, and the result is dramatically lower energy,” Hanson continues. “There’s not any one silver bullet. There’s a wide range of things that we do to make subthreshold possible.”

More than Moore’s Advances in sub-threshold circuitry and voltage optimization will become more prevalent as Moore’s law continues to eke out smaller process nodes and the gate-to-source channels of MOSFETs shrink in size, necessitating lower and lower supply voltages as well as increasingly smaller thresholds. As Moore’s law advances towards the limits of physics, power consumption will become as much of a tenet of computing’s first amendment as performance, if not replace it.

18

“One of the challenges we see for Ambiq at a system level is that, as we’ve driven energy efficiency of the processor down, the overall contribution of the microprocessor to the system has gone down to the point where customers say, ‘Hey, you knock another 10x out of the energy, it doesn’t make a difference because you’re already very, very low,’” says Hanson. “What they really need is for us to knock that energy down by 10x, but they need a commensurate increase in performance to take advantage of that. That is to say, if I reduce energy by 10x, they want to see an accompanying 10x increase in performance so they can stay in the same power envelope but dramatically increase the processing power. We focus a lot on that as a company: How can I both increase performance and continue to reduce energy?

“We saw Moore’s law in the high-performance computing industry with PCs, notebooks, and phones. We saw Moore’s law lead the way in allowing us to deliver something better and more incredible every year so we could add more features, but we were kind of stuck in the same form factors, the same battery life, etc.,” Hanson continues.

“We’re going to see the same thing happen with power consumption, and that means that we’re constantly going to be talking about how we need lower energy in every component.”

What’s new with the mbed OS?

By Brandon Lewis, Technology Editor

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 TrustZonebased 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 19

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 launched mbed in 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

mbed OS 2 (”Classic”)

mbed Drivers

mbed Online IDE

Project Export

mbed RTOS

Hardware Components

mbed OS 5

Community Libraries

Merged

mbed OS 3

Fork

mbed Drivers

mbed TLS

mbed uVisor

mbed Thread & 6LoWPAN

MINAR

mbed Cloud Client

Reworked

Figure 1 | mbed OS 5 integrates the two codelines of mbed 2.0 (“Classic”) and mbed 3.0 (“Eventing OS”) into one unified platform.

20

ARM mbed

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.

“mbed 5 incorporates key features of its predecessors while also introducing capabilities that streamline mbed development.”

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

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

3. 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 21

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 Figure 2 | MultiTech’s MultiConnect mDot LoRaWAN could we have been?” Quant says.

“Most of the Cortex-Ms have had ARM module was the first deployable product to support the mbed platform, and is now compatible mbed ported onto them, so it gives us with mbed OS 5.1. a standard software platform on what is a very, very high running design across latest release, mbed OS 5.1, which is still multiple manufacturers. free for developers, has currently been ported to 40 target platforms. According “We needed something that didn’t lock to sources at ARM, the mbed platform is us into a vendor chain. mbed ticked now seeing 300,000 – 350,000 compiles those boxes,” he continues. “It’s now per week. expanding. They’ve rethought what mbed in use they were doing and made it more MultiTech Systems provides device man- appealing to the embedded power user agement and access provisioning tools while also making it more appealing to and services for IoT customers on top programmers working at a service layer. of wireless connectivity modules based mbed has given us the ability to put that on Cortex-M-class processors, which it together without having to reinvent the leverages due to their low power, cost, wheel ourselves.“ and wide availability. The company has long ported mbed to its devices as a The trials of mbed are indicative of the means of abstracting away the chal- IoT as a whole, with IT/OT integration lenges of managing vendor-specific pro- revealing nuanced challenges in marcessor variations, while also enabling rying two distinct technology segments. them to focus on their core compe- Additional announcements surrounding tency. The company is now seeing the mbed are scheduled around ARM mbed OS compiled upwards of 5,000 TechCon in November, which, hopefully, times per week across its products, one will help advance that unification.

22

Everything you need to know.

Exactly what

you’re looking for.

Co-Sponsored  ARM  Automotive  Embedded Software & Tools  Flash Storage  Internet of Things



Download the app: itun.es/isp8hn opsy.st/kindlefireamaz



E M A G

 Medical  Radar & Electronic Warfare  Safety Certification  Unmanned Systems

Read the E-mags: embedded-computing.com/emag

E M A G

SPONSORS

Š 2016 OpenSystems Media, Š Embedded Computing Design. All registered brands and trademarks within the ARM E-mag are the property of their respective owners.