by WARREN KURISU, Mentor Graphics
Operating systems and the way they handle tasks can make or break applications such as activity trackers and fashion electronics.
The wearables industry is still in its early stages of development. The financial firm Morgan Stanley estimates that the wearables market could become a $1.6 trillion business in the next few years. But a lot of software work will have to go into realizing these trends. A full-featured, real-time operating system (RTOS) can help get smart wearable products up and running quickly.
The physical form factor of most wearable devices leaves little room for the electronics. A wearable device can pack an amazing array of peripherals for its size, but memory capacity is the one area where geometry can’t be out-maneuvered. An RTOS can help minimize memory demands in wearables. The RTOS itself can have a small footprint and provide a deterministic behavior that helps keep code compact. But it must also scale down to a minimal size in both code and data requirements 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.
Wearables, for the most part, are extremely small. They often use an 8-bit MCU clocked at less than 25 MHz, with only 8 K of memory. Low-power ARM-based processors are good candidates for wearable devices because of their small form factor and minimal power requirements. Recent products taking the ARM approach include the Pebble watch and the Omate Racer Smartwatch.
Omate is a hardware and software design company. Its Racer Smartwatch is a stand-alone telecom mobile device that works with numerous iOS and Android applications using Bluetooth connectivity to a smartphone. Users can send and receive incoming calls, social media updates, messages and reminders, among other notifications.
The Racer Smartwatch carries an ARM7 MediaTek Aster SoC, the industry’s smallest wearable SoC. The MediaTek chipset relies on the Nucleus RTOS from Mentor Graphics for power management and wireless programming. Nucleus can scale voltage and frequency for reduced power consumption of a single or multiple operating system platform, maximizing cycles-per-watt to conserve power.
With built-in power management and connectivity capabilities, the RTOS helps with power-sensitive wireless communications applications. Nucleus also applies a “system power state” for each of the peripherals in the SoC. This lets the SoC independently control the power to different blocks, modules or peripherals, allowing various applications to run simultaneously.
More complex designs often include feature-rich SoCs clocked in the hundreds of megahertz 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 a graphical user interface (GUI) and wireless connectivity to the Internet or cloud. It takes a full-featured RTOS to power these more complex designs.
The compelling difference between wearables today and devices from a few years ago is the greater availability of wireless connectivity options. Wireless connectivity spans the range from Near Field Communication, Bluetooth/BLE and WiFi, up to huge mobile cellular networks. This is an area where technology, protocols and options change rapidly. Similarly, solutions currently deemed to be too expensive today can easily become the economical standard tomorrow.
Communication technologies can change over the lifetime of a wearable device, or even during the development cycle. The operating system environment can help handle these changes to minimize the impact on applications.
RTOSs have been around for years, and countless embedded devices have employed them. The typical RTOS incorporates basic capabilities such as a kernel, scheduler, file system, connectivity and graphics support. An RTOS for wearable devices also has stringent requirements in three other critical areas: scalability, space partitioning and comprehensive power management.
One advantage of an RTOS environment is the ability to treat the RTOS application programming interface (API) as the target machine. This lets software personnel develop applications to that specification. Beneath the RTOS, middleware and device drivers handle the hardware directly. So an application can adapt to the particular details of the a specific product version by working with the API. This can happen through dynamic evaluation of the features at runtime, or through selective build options during compilation and linking.
The Nucleus RTOS lets applications work with a wide variety of peripheral combinations. It also lets developers transport applications and use them in different processor variations, families, and architectures. Moreover, it lets a reduced feature version of an application work on a single-chip MCU and behave much the same way as a full-featured version on a high-performance MPU platform.
Space domain partitioning
Space domain partitioning created through the use of light-weight processes can make systems more reliable and prevent one subsystem from bringing down another. The idea is to let limited memory resources be re-used by loading and unloading memory modules based on the application needs. These features are normally found only in high-end or general-purpose OSs that use cores containing memory management units (MMUs) for partitioning and virtualizing memory. The Nucleus RTOS brings these functions to Cortex M devices that do not incorporate an MMU. In other words, it can handle space domain partitioning without the overhead of virtualizing memory. Processes can load from a file system to memory or run directly in RAM or Flash (XIP).
RTOSs that are equipped to handle spatial partitioning can configure the MPU at run time to establish memory regions in both kernel and user space. APIs can be used to load processes at runtime or based on the use-case during execution.
Battery life is obviously critical for wearables. Modern processors contain numerous power saving capabilities. Examples include idle modes, sleep modes, dynamic voltage frequency scaling (DVFS) and hibernation modes. If the underlying operating system does not have a framework to take advantage of the low-power features in the silicon, the developers must generate the code to do so. The amount of code required creates more complexity and can add to code bloat.
Power saving features are built into the silicon. However, their use becomes complicated in the absence of an operating system designed to handle them. For instance, consider the process of implementing a simple power-saving feature such as lowering the frequency. Before the processor can shift frequency, software must know the state of each peripheral device. Additionally, it must know if each peripheral device can operate at the new lower frequency—some may not. Software must also know how long each active device can be taken offline to effectuate the frequency shift without losing any data. Some devices can only go offline for a short period, so they must be taken offline last and brought back online first. And after the frequency shift, devices like the UART will need their baud rate reset.
Obviously, the management of all these details takes a significant coding effort in the absence of an RTOS with an API for power management. But with an API available, a frequency shift can happen with a single API call. All in all, a power management framework provides a way for API calls to control all system devices.
The power management framework approaches the conservation of power use from four directions: 1) system states are used to control peripheral power; 2) dynamic voltage scaling—basically, reducing the operating voltage—focuses on the entire system; 3) idle power management prevents expending energy without a specific goal; and 4) hibernate/sleep modes that let the system go off-line during long periods of inactivity.
A power management framework lets software developers write code to conserve power without creating code bloat or increasing the footprint. A power management framework also lets software developers plan for power specifications early in the design cycle. The resulting code can be tested throughout the development process to ensure power consumption remains at targeted levels.
Finally, wireless connectivity is important for any IoT application. RTOSs, such as Nucleus, include facilities for handling wireless standards such as WiFi, Bluetooth/BLE, and 802.15.4. Additionally, adaptation layers like 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks)provide routeable addressing to IoT devices based on IPv6, the most recent version of the Internet protocol. In short, RTOSs will need to support numerous wireless schemes and IoT protocols, as well as methods of integrating wireless devices into the cloud.
References
Mentor Graphics, Nucleus RTOS
www.mentor.com/embedded-software/nucleus/
Wikipedia page for real-time operating systems
www.en.wikipedia.org/wiki/Real-time_operating_system
Wikipedia page for Nucleus RTOS,
en.wikipedia.org/wiki/Nucleus_RTOS
Leave a Reply