The challenges of the Internet of Things

Although there are now many connected devices available, there is still a long way to go to unlock the full potential of the Internet of Things (IoT). Microcontrollers with Ethernet connectivity, built-in PHY, or complete modules with W-iFi connectivity are a start, but there are issues to resolve.

A great many microcontrollers are suitable for IoT applications. With low power a key requirement for what are often super-portable designs, ARM processors are one good choice. Microcontrollers with these cores are available from many MCU suppliers. For general data processing and normal I/O control tasks, the ARMv6-M architecture provides the best energy efficiency. The ARMv7-M architecture provides additional instructions such as hardware divide, bit field processing, and multiply-accumulate (MAC) to accelerate data processing. The Cortex-M4 provides instructions such as SIMD to enhance signal-processing performance. A floating-point unit is a Cortex-M4 option. (See Fig. 1 .)

Fig. 1: The Cortex-M0, -M0+, and -M1 processors use the ARMv6-M architecture, while the Cortex-M3 and -M4 use ARMv7-M, with a larger instruction set. 

In typical IoT applications, processor system requirements are low power, high code density, high performance, memory space, and addressing modes. It also has to be OS-friendly and be secure.

 Power

Many of the devices in IoT systems are “always on,” although the processors or microcontrollers could, and should, be in sleep mode most of the time. The energy consumption of the system can be considerable over a period of time and the power wasted can be significant without good energy efficiency or very low standby power. Many Cortex-M microcontrollers today need less than 200 µA/MHz during operation. Lower power consumption can also lower EMI, which reduces both the power required for wireless data communication and the risk of interference in medical or mission-critical applications.

 Ease of system-level integration

All Cortex-M processors use the Thumb instruction set, which provides a mixture of 16- and 32-bit instructions under one operation state. In most cases, the 16-bit instructions are used for better code density. High code density allows the use of a smaller flash memory.

Typically 16-bit instructions are used so the processor only needs to fetch instructions every other clock cycle. This reduces power consumption, and allows more bus bandwidth for other data transfer operations. For example, you might have communication DMA operations in parallel with the processor's memory access and lower processor bus usage helps.  .

Although it might be possible to implement an IoT product using legacy 16-bit or even 8-bit microcontrollers, the 32-bit Cortex-M processors are able to handle the increased data and enhance the user experience, such as a GUI, and support cryptography.

 Memory space and addressing modes

An IoT device will likely require more memory for data used in network packet processing and need more program code size than typical embedded apps without connectivity. In most 8-bit and 16-bit microcontrollers, the architecture only supports up to 64 or 128 Kbytes of total memory space. In the Cortex-M microcontrollers the 32-bit linear address allow up to 4 Gbytes of total memory space. The various address modes of memory access make the architecture C-friendly as well as easy to program and debug.

It may also be essential to use an embedded OS to handle different tasks. The Cortex-M processor architecture has a dual stack pointer mechanism that allows an OS to be implemented easily, and enable efficient memory usage. The processors include a 24-bit timer dedicated to OS System Tick interrupt generation to facilitate OS porting.

Security issues

The MPU controls access to different memory regions. Using privileged and unprivileged execution levels, many tasks can be run in unprivileged mode and prevent a hacker accessing protected areas even if a task is compromised.

Higher performance allows sophisticated security measures to be implemented, for example, checking to validate external inputs from the Internet, and encryption/decryption of data transfers. In addition, Cortex-M processors have a fault exception handling capability, which is triggered when certain errors are detected. When an error condition occurs, the software can choose a remedy action, e.g. the system can be restarted.

Connectivity and performance

For IoT applications, the microcontroller suppliers integrate an Ethernet or Wi-Fi interface, or other communication interfaces likes ZigBee or RFID. In products with an LCD display and GUI, and/or USB, audio, or memory cards, the performance required can be a lot higher.

Recently Cortex-M processor-based microcontroller products have been running at 100 to over 200 MHz. This high-frequency capability with a power profile, and price point, similar to the best 16- or 8-bit microcontrollers, make them especially suitable for IoT products (see Fig. 2 ).

Fig. 2: Active current of low-power Cortex-M microcontrollers.

Design scalability

All Cortex-M processors have an AMBA scalable on-chip bus protocol to connect memory and peripherals. It allows multiple processor cores, or additional bus masters like smart peripherals that can initiate data transfers, to be designed with shared memory and shared peripherals.

Designers can easily switch between low-cost MCUs with Cortex-M0/M0+ to higher-performance Cortex-M4-based devices. The consistent architecture allow easy porting of application code across processors.

Software integration challenges

While the current generation of ARM microcontrollers is very capable of handling IoT applications, there are significant challenges in software to address. A single IoT device might contain product-specific application code, a device driver library, RTOS, TCP/IP stack, wireless/wired communication stack, Internet server/client software, GUI library, file system, a codec for image/audio processing, a cryptography library, and a toolchain-specific runtime library. Integrating all these software components can be challenging. With over 30 embedded OSs that can be used with Cortex-M microcontrollers and compiler suites from over 10 vendors, and many more middleware products, coordination on software development is needed.

In order to help various software vendors to work together, ARM has created the CMSIS (Cortex-M Software Interface Standard). CMSIS covers a number of areas (see Fig. 3 ):

CMSIS-Core: a compiler-independent API for software to access features on the processor such as interrupt control, system tick timer (SysTick) and special instructions

CMSIS-DSP: a library containing commonly used DSP and related functions optimized for Cortex-M4, and supported on all Cortex-M microcontrollers

CMSIS-SVD: System view descriptions is an XML-based data set allowing debuggers from different vendors to understand the available peripherals in a microcontroller device

CMSIS-RTOS: A set of API for middleware and application code to access features, such as task management, in an embedded OS;

CMSIS-DAP: a reference USB debug adaptor design that can be ported to microcontrollers with a USB interface.

CMSIS-PACK: a software component package mechanism to allow easier software component integration.

Fig. 3: The CMSIS currently addresses five integration areas.

At the same time, IoT brings extra market opportunities for middleware — file systems, images and audio processing, VoIP, network diagnosis tools, and connectivity — to help better collaborations, ARM worked with Avnet to set up the online Avnet Embedded Software Store.