What features do micros need in order to meet the challenges posed by the IoT?

Microcontrollers with Ethernet connectivity, built in PHYs or complete modules with Wi-Fi connectivity are a start, but there are issues to resolve. Lately, more Cortex-M based mcus have become available, many of which have Ethernet connectivity. Generally, they satisfy the requirements of IoT applications: low power; high code density; high performance; and security. Processors also need adequate memory space and addressing modes and must be OS friendly and secure. Many IoT systems are 'always on', although the mcus could be in sleep mode most of the time. Energy consumption over time can be considerable and the power wasted can be significant without good energy efficiency or low standby power – critical for battery powered products. Cortex-M processors provide architectural sleep modes, clock gating support and multipower domains, as well as ultra low idle power during sleep modes. The Cortex-M0+ processor further reduces system level power consumption by reducing the number of flash memory accesses required for a given task. Many Cortex-M based mcus need less than 200µA/MHz during operation and lower power consumption can also lower emi. This, in turn, reduces the power required for data transmission and the risk of interference in medical or mission critical applications. Cortex-M processors are based on ARM's Thumb-2 technology. The Thumb instruction set provides a mixture of 16 and 32bit instructions under one operation state; in most cases, 16bit instructions are used for better code density. High code density allows the use of a smaller flash memory, which reduces cost and lowers power consumption. Typically, 16bit instructions mean the processor only needs to fetch instructions every other clock cycle, allowing more bus bandwidth for other data transfer operations. In devices with a fast Ethernet interface, for example, a DMA controller might need that bandwidth to transfer data between memory and the Ethernet interface. Although it might be possible to implement an IoT product using legacy 16bit, or even 8bit, mcus, 32bit Cortex-M processors can handle the increased data, enhance the user experience and support cryptography. A 32bit mcu also has the headroom to handle unexpected network traffic and might provide a better chance to survive a Denial of Service attack. An IoT device will require more memory for the additional network packet processing data. More memory may also be needed for the program image. Most 8 and 16bit mcus architectures only support up to 64kbyte or 128kbyte of memory. Cortex-M mcus use a 32bit linear address, which supports up to 4Gbyte of memory. Various memory access address modes also make the architecture C friendly and easy to program and debug. It may be essential to use an embedded OS to handle different tasks. The Cortex-M architecture has a dual stack pointer mechanism that allows an OS to be implemented easily, while making efficient use of memory. A 24bit timer, dedicated to OS System Tick interrupt generation, allows an OS to be ported across different Cortex-M based devices. For safety critical applications, the embedded OS can use the optional memory protection unit (MPU) to prevent an application from corrupting data in other tasks. The MPU controls access to different memory regions. Using privileged and unprivileged execution levels, many tasks can be run in unprivileged mode, preventing a hacker from accessing protected areas. For IoT applications, mcu designers need to integrate various peripherals and features, such as an Ethernet, Wi-Fi, Zigbee or rfid. Many will include data handling enhancements, such as a DMA controller, or a multilayer bus matrix. Hardware accelerators for cryptography drive the performance requirements, which may be higher still in products with an LCD and GUI, or with additional connectivity such as USB, audio or memory cards. Designers can also switch between Cortex-M0/M0+ based mcus and those designed around the Cortex-M4 core. The consistent architecture and CMSIS – the Cortex-M Software Interface Standard – allow easy porting of application code across processors. While the current generation of ARM based mcus can handle IoT applications, there are significant software challenges to address. One 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 toolchain specific runtime library. As software becomes more complex, middleware needs to interact with the OS. Currently, middleware packages which need to be RTOS independent have to resort to an extra OS porting interface layer; an example is the emulation layer for LwIP (see fig 1). However, OS porting can increase software development time and middleware has to be compatible with multiple embedded OS, requiring a consistent OS API. The only TCP/IP stacks currently supporting IPv6 are LwIP and uIP. While Windows, Linux and Mac platforms support IPv6, home/business broadband routers or ISPs might not. Setting up a gateway on the network to handle IPv6 to IPv4 tunnelling only adds complexity. Although IPv6 can be tested in a controlled environment, you might have no control over which TCP/IP protocol will be used in the field. While mcus will have to cope with dual stack implementations, the performance and loss of IPv6 communication could be worse than IPv4 in some cases. Headroom may need to be added for communication performance/latency. More program codes are needed to implement a dual stack. While this is not a problem for pc or mobile platforms, mcu code size is generally limited and increases with secure communications. Here, the code density and 32bit addressing of ARM based mcus can be an advantage. It is impossible to install firewall software on embedded devices, yet the migration to IPv6 means more IoT devices will be connected directly to the Internet with a unique IP address, instead of sheltered in a local network behind Network Address Translation. Many mcus have built in AES encryption accelerators and random number generators. Other software is available to support secured connection, such as Secure Sockets Layer (SSL) and Secure Shell (SSH), or IPSec at IP level (see fig 2). However, software developers often have to port the layers – a difficult task for inexperienced engineers. Again, a 32bit processor is essential as the typical SLL code is at least 50kbyte and overall code sizes can exceed 128kbyte. Standardisation is essential; not just for communication protocols, but also in the transaction and up to the application. The protocol designs must be scalable, energy efficient, secure and low cost. Organisations like OPC Foundation, The Internet of Things Initiative and the Weightless SIG are looking to establish standards that enable a common platform for IoT development. Meanwhile, ARM has worked with Avnet to set up the Avnet Embedded Software Store, where users can find middleware such as file systems, images and audio processing, VoIP, network diagnosis tools and connectivity tools. Recently, some Cortex-M based mcus have been running at more than 200MHz. This high frequency capability and high execution efficiency – but with a power profile and price point similar to 16bit or 8bit mcus – make them suitable for IoT products. Joseph Yiu and Andrew Frame are with ARM.