A long time ago in a galaxy far, far away…embedded devices were single-threaded, standalone, and relatively straightforward to design. Those days are clearly over. With 50 billion connected devices predicted for 2020—the so-called Internet of Things (IoT)—even the most deeply embedded systems will face issues with scalability, modularity, connectivity, and reliability that were far more manageable in the past.

There are numerous on-ramps to the IoT, but choosing between them may require some rethinking. A recent Micrium white paper sorts out the issues and suggests some strategies for integrating your devices into the IoT.

Designs for the industrial IoT will be different from those serving carbon-based life forms (human IoT), with the former needing to last far longer, plus be more autonomous, secure, and resilient.

The IoT is likely to be different from and run parallel to the Internet of People (IoP). The current Internet was enabled by IPv4, which still carries 96% of all Internet traffic. With a huge 128-bit address space, route allocation, multicasting, and other advantages, IPv6 should do for the IoT what IPv4 did for the IoP. In the process it will present challenges for embedded developers, not the least of which will be shoe-horning the software stack into the limited RAM of an MCU.                                  

How It Stacks Up

Networked devices require communications capabilities that can quickly expand stack size. Wireless access to the IoP is typically via Wi-Fi, Bluetooth, or Zigbee. There are three approaches to handling a large stack like Wi-Fi:

  1. Run the TCP/IP and Wi-Fi stacks on the main processor;
  2. Use a Wi-Fi module, running the Wi-Fi stack on the Wi-Fi module and the TCP/IP stack on the MCU; or
  3. Run both the Wi-Fi and TCP/IP stacks on the Wi-Fi module.

Micrium suggests using solution #1 for high-production runs; #2 for medium volume; and #3 for low volume, where you’re trading off cost for reduced development time.

While they may share a common kernel and low-level services, the software requirements for industrial and consumer IoT can vary considerably. A battery-powered wireless sensor node might use a low-power MCU with an efficient, small-stack wireless protocol such as Bluetooth or 6LoWPAN; the Wi-Fi stacks would reside on an IP-based network. A consumer device with a larger, rechargeable battery could run Wi-Fi directly and possibly even host a Java VM.

Because of their limited RAM size 8/16-bit low-power MCUs will usually work alongside a 32-bit processor, with the former (RL78 or RX1x) processing sensor data and the latter (RX6x or RZ) handling the communications tasks. With up to 10 MB of RAM the RZ/A1H can accommodate the TCP/IP stack as well as a small RTOS and middleware.

An RTOS provides a software framework that can integrate a lot of functionality. At the same time it needs to be scalable, secure, and have a small memory footprint. Linux is a very capable, widely used OS for embedded applications. Even scaled down it lacks a small memory footprint, which rules it out for 8- and 16-bit MCUs as well as many 32-bit ones. Micrium offers a scalable software framework based on its µC/OS-III RTOS as well as certification kits for avionics, medical, and industrial control applications.

IoT-Specific Protocols

The client/server Internet browser model is based on HTTP, which is a pretty heavy protocol for most IoT applications. In July 2013 the IETF released the Constrained Application Protocol (CoAP) for use with low-power and lossy (constrained) nodes and networks (LLNs). CoAP is a lightweight asynchronous protocol that maps directly to HTTP but requires a smaller stack and less processing horsepower.

MQ Telemetry Transport (MQTT) is an open source protocol that was developed and optimized for constrained devices and low-bandwidth, high-latency, or unreliable networks. It is a publish/subscribe messaging transport that is extremely lightweight and ideal for connecting small devices to networks with minimal bandwidth.

The table below summarizes some Internet-specific IoT protocols that have been developed to meet the requirements of devices with small amounts of memory and networks with low bandwidth and high latency:

This post has highlighted just a few of the topics covered in much more depth in Micrium’s white paper—which also deals with integrating cloud computing and back-end services into embedded designs; choice of programming languages; and new ways of thinking about embedded design as the IoT takes off. It’s well worth downloading and reading.