The definition of a “Thing” in the Internet of Things varies a lot. At Micrium, we define a Thing as an embedded computing device (or embedded system) that transmits and receives information over a network.
What is an Embedded System?
Embedded systems are based on microcontrollers (MCUs), and run software with a small memory footprint. Some Linux and Android-based systems can also be described as embedded systems. But usually, these general-purpose operating systems require an application processor, and have additional capabilities such as dynamic application loading. This is why MCU-based embedded systems are often described as deeply embedded systems, versus the more general definition of embedded systems. For us at Micrium, these deeply embedded systems are the Things in the Internet of Things.
MCUs featuring 32-bit architectures have dropped in price over the last several years, and are becoming common in embedded systems. The greater capabilities of 32-bit MCUs present new choices for embedded systems developers.
IoT device software architecture
For 8 and 16-bit MCUs, software has often been written using a foreground/background approach (that is, a super-loop). But with 32-bit MCUs dropping in price, a real-time operating system (RTOS) is now the preferred option, allowing for more flexible and extensible software to run on these systems. A complete RTOS – with a kernel, GUI, file system, USB stack, networking, and more – can fit in a memory space of less than 1MB. With an RTOS, the software architecture of an embedded system can be more flexible. Troubleshooting and adding new features becomes dramatically simplified. It is also simpler to perform firmware upgrades. In summary, it just makes sense to use an RTOS with a 32-bit processor.
Processors for the Things
So which processor architecture should you choose? To date, the main contenders are Intel and ARM.
Intel has positioned its Atom processor as an embedded CPU, and has targeted it at the industrial Internet. The new Intel Quark, on the other hand, is aimed squarely at the deeply embedded system market.
ARM’s family of processors includes a wide range of 32-bit architectures that are licensed to a large number of suppliers. The ARM chips are among the best low-power architectures, and processor software start-up is a lot simpler compared to Intel.
It’s commonly believed that IoT hardware should always be low-cost, so that we can flood the planet with IoT devices (an IP address for every light bulb). But in fact, low-cost is not the solution for every application, especially when IP networking is concerned.
First off, a TCP/IP stack is not a small piece of code. Of course, you can find open source TCP/IP stacks that fit within 32 KB of code space, but usually this is achieved by taking liberties with the TCP/IP standards. This can cause problems because you may need a device that can operate on the vast majority of IP networks.
Second, TCP needs a fair number of network buffers to work efficiently, which require precious RAM. And, if you need to use Java, then the IoT device will require an RTOS as the foundation to run the Java virtual machine (JVM). All these elements work against the choice of a low-cost architecture for the IoT device.
Picking an MCU
Which MCU makes a good starting point when designing an IoT device?
- For an ARM processor in the IoT device, the Cortex-M0 is perfect. For gateways, the ARM Cortex-M3/M4 or Cortex-A are good choices because of their greater processing capabilities.
- For non-ARM processors, a good option is the Renesas RL78 or RX100 for the IoT device, and the Renesas RX600 or RZ for the gateway.
Either way, new processors with more flash memory and more RAM appear on the market regularly, and always at a lower cost.
Until recently, a common strategy to save power in an embedded system was to execute as quickly as possible, and then go into sleep mode immediately. But there are now processor core architectures that consume almost no power, although with reduced performance. This is an attractive option for a WSN edge node design. This tradeoff of power for performance means designing transistors that operate close to (or below) their threshold voltage.
ARM is currently working on a processor core optimized for operation close to the threshold voltage of CMOS transistors, and at clock frequencies of the order of tens of kilohertz. ARM’s near-threshold design is compatible with the Cortex-M0 architecture, which is good news for the software community. Near-threshold designs are easier to achieve, as ARM can work with multiple foundries without having to characterize the chip process. This is not the case with sub-threshold design, which would require a custom manufacturing process, and which brings greater risk.
The programming languages used in deeply embedded systems include C, C++ and sometimes Java. It is important to note that Java always runs on top of an operating system. So, your choice is not between C/C++ or Java; it is whether you will use C/C++ and Java.
Java is attractive for IoT devices because the number of Java developers worldwide brings tremendous growth potential to the industry. Oracle and ARM estimate there are about 450,000 embedded software engineers across the globe, and about nine million Java developers.
The resource requirements for a Java engine are not negligible. Oracle’s Java ME Embedded is designed for small devices, and Oracle estimates the following system requirements:
- System based on ARM architecture SOCs
- Memory footprint (approximate)
- From 130 KB RAM/350KB ROM (for a minimal, customized configuration)
- To 700 KB RAM/2000 KB ROM (for the full, standard configuration)
- Very simple embedded kernel, or a more capable embedded OS/RTOS
- At least one type of network connection (wired or wireless)
These numbers don’t meet Micrum’s definition of a deeply embedded device. The above requirements, plus the embedded kernel and the communication stack, pushes the total into megabytes of ROM and RAM. Clearly, Java’s role in IoT devices will be limited to more capable and expensive systems.
When cost is not an issue, you can select a single powerful processor to run all the tasks required of your device. However, a common engineering compromise is to use two processors in the sensor/actuator device. One low-cost processor (8 or 16 bit) is used for the physical-world interface, and a second 32-bit processor runs the network interface. This second processor is often placed in a separate module, one that has already been certified for the protocol and FCC compliance.
IoT device with two processors
When two processors are used, a real-time kernel is not strictly required for the sensor/actuator processing, but is strongly recommended for the communication module.
A gateway connects two dissimilar networks so that data can flow between them. Usually this is a connection between a proprietary network and the Internet.
For example, in home automation, different utilities companies may install a wide variety of IoT devices in your house, each with their own gateway. These can include electricity or gas, water, phone, Internet, cable/satellite, alarm system, medical devices, and so on. Some of these gateways may require additional functions, such as local storage, or a user interface.