By Warren Kurisu
How quickly times have changed. It wasn’t too long ago when wearables were a type of fad for those early adopters who couldn’t wait to sport the latest fitness band or smartwatch. But as new innovations, product successes, and business start-ups enter the market, there has been a noticeable change in the role of wearables, one which can significantly impact the end-user, the manufacturer, and the embedded software developer.
While the wearables industry is still in its early stages, Morgan Stanley estimates that the wearables market has the potential to become a $1.6 trillion business in the next few years. Already new innovations have been introduced in not only the traditional watch sector, but also in apparel and healthcare.
This article touches on a few design considerations software developers need to keep in mind before they embark on their next wearable device and how a full-featured, real-time operating system (RTOS) can assist in meeting those goals.
Why an RTOS?
To accommodate the physical form factor of a wearable device, the electronics have very little volume available for the components. The physical size limitation typically results in a microcontroller (MCU) system-on-chip (SoC) as the core processing engine. While a wearable device can pack an amazing array of peripherals for its size, the issue of memory capacity is the one area where geometry can’t be out maneuvered. If an RTOS is to be considered for both its small footprint and deterministic behavior, it must also scale down to the most minimal size in both code and data requirements in order to survive at the lowest end of the device spectrum. This same RTOS must also be able to scale up to the most full-featured range of services.
Tapping into the hardware
Wearables, for the most part, are extremely small often utilizing an 8-bit MCU clocked at less than 25 MHz, with only 8K of memory. Low power ARM®-based processors are ideal for wearable devices because of their small form factor and minimal power requirements.
More complex designs often include feature-rich SoCs clocked in the hundreds of MHz and megabytes of memory. These hybrid systems may include special-purpose processors and multiple application and/or microcontroller cores. The more complex SoCs often require the operation of a graphical user interface (GUI) and wireless connectivity to the Internet or cloud. To power these more complex designs, a full-featured RTOS is required.
Modern connectivity options – a must
The compelling difference between wearables today and devices from a few years ago is the greater availability of wireless connectivity options. Connectivity is achieved via access to the “Internet of Things” (or cloud), or to a local intermediary device (the user’s smartphone) which eventually provides a pathway to the Internet.
Wireless connectivity spans the range from Near Field Communication, Bluetooth/BLE, and Wi-Fi, up to very large mobile cellular networks. This is an area where technology, protocols, and options are changing rapidly. Further, the dynamics of the costs of these systems is such that solutions currently deemed to be too expensive today can easily become the economical standard tomorrow.
It’s also quite possible that these technologies will change over the lifetime of a wearable device, or even during the development cycle. Isolating the application level to accommodate these changes is most effectively handled by the operating system (OS) environment.
How is an RTOS for wearables different from other RTOSes?
Commercial and freely available RTOSes have been around for years, and countless embedded devices have been built with them. The “typical” RTOS consists of some basic capabilities, such as a kernel, file system, connectivity, and graphics support. While these same capabilities are required for today’s emerging category of full-featured wearable devices, developers now are finding themselves in need of a solution that fully addresses increasingly stringent requirements in three critical areas: scalability, space partitioning, and comprehensive power management.
A distinct advantage of an RTOS environment is the ability to consider the RTOS application programming interface (API) as the target machine and develop applications to that specification. Beneath the RTOS layer, the incorporated middleware and device driver collection provide the adaptation to the physical hardware. An appropriately designed application can adapt to the particular details of the underlying instantiation of a specific product version. This adaptation can be achieved through dynamic evaluation of the included features at runtime, or selective build options during compilation and linking.
Small, battery-powered devices require highly efficient methods that consume minimal resources and are amicable to minimizing power modes. The Nucleus RTOS from Mentor Graphics allows common applications to span not only a wide variety of peripheral combinations, but also allow applications to be transportable across different processor variations, families, and architectures. A reduced feature version of an application can share the same environment on an MCU device as a full-featured version would experience on a high-performance MPU platform.
Although there are plenty of commercial RTOSes to choose from, many of these RTOSes do not provide a mechanism for embedded developers to design software architected for spatial partitioning. With a framework built into the operating system, the MPU can be easily configured at runtime to establish memory regions in both kernel and user space. Intuitive APIs can be used to load processes at runtime or be based on the use-case during execution. Nucleus employs a light-weight approach to a process model (Figure 1). The MPU in the ARM Cortex-M3/M4-based SoCs can be used for spatial domain partitioning without the need (or overhead) to virtualize memory. Processes can be loaded directly from ROM or Flash into memory. And, with pre-linked embedding, processes can execute in situ in Flash, which is a feature commonly required in MCUs with very limited RAM. Utilization of the MPU in Cortex-M based SoCs, gives embedded developers a powerful feature to design an embedded system for a wearable device that gives the perception of behaving much larger than what is actually inside.
Comprehensive power management
Battery life is obviously a critical factor for wearables. Today’s modern processors contain an impressive array of effective power saving capabilities. Contemporary MCUs offer low-power features such as idle modes, sleep modes, dynamic voltage frequency scaling (DVFS), and hibernate. If the underlying operating system does not have a framework to take advantage of the low-power features in the silicon, the amount of code required not only creates a new level of complexity but can also add to code bloat.
Just as modern software architectures abstract hardware functions through device drivers, a power management framework (Figure 2) provides a structured mechanism for all system devices to be controlled using intuitive APIs calls. Any alteration of one device that impacts other devices results in a coordinated transition across all involved subsystems. The power management framework approaches the conservation of power usage from four directions: 1) system states are used to control peripheral power; 2) DVFS focuses on the entire system; 3) idle power management prevents expending energy without a ascertainable goal; and 4) and hibernate/sleep modes allow the system to go off-line during long periods of inactivity.
With a power management framework, software developers can effectively write code to meet power requirements without creating code bloat or increasing footprint. A power management framework allows embedded software developers to consider power specifications early in the software design cycle. Code can be written to minimize both the footprint and power consumption – and tested throughout the development process to ensure power requirements are achieved.
The opportunities for wearables are only limited by one’s imagination. No doubt, designing and deploying of an embedded system for a wearable device is just one piece to the overall jigsaw puzzle. But progress has been made at the kernel level. Being able to take advantage of today’s power-aware hardware by using an adaptable real-time operating system is a critical first step. Having a full-featured RTOS helps developers address increasing SoC complexity as well. To stay cost-effective and competitive, developers must build their wearable device upon a fully featured platform that is scalable, includes a process model, and has a comprehensive power management framework.
About the author
Warren Kurisu is the Director of Product Management in the Mentor Graphics Embedded Systems Division, overseeing the embedded runtime platform business for the Nucleus RTOS, Mentor Embedded Linux, virtualization and multicore technologies, and graphics and development tools. Warren has spent nearly 30 years in the embedded industry, both as an embedded developer and as a business executive, working broadly in industries including Aerospace, Networking, Industrial, Medical, Automotive and Consumer. Warren holds a master’s degree in Electrical Engineering from the University of Southern California and a Master of Business Administration from the University of California at Berkeley.
Mentor Graphics, Inc.