Microcontroller and Connectivity Options for Smart Home and IoT Devices



IoT end nodes and gateways that offer the best combination of energy-efficiency, performance, cost effectiveness and appealing features—regardless of MCU bit size—will be in the driver’s seat in the race to our IoT future.

We’re at the dawn of a new era in connectivity and convenience unlike anything we’ve experienced before. The Internet of Things (IoT) promises to deliver on the vision of anywhere/anytime knowledge and control of our home and work environments, and depending on the side of Geoffrey Moore’s “chasm” you sit, the IoT may already be here. Today I can monitor my connected home and ensure my family is safe, optimize my home energy usage and check on my pets, all while at home or on the road. There will be a tipping point; a handful of innovative consumer products and services that even the late adopters won’t be able to ignore, after which there will be little question that the IoT has arrived.

If it hasn’t already happened, soon your company’s management team will propose products to participate in the IoT. How will you respond? The good news is that many of the application building blocks for the IoT are available today, just waiting for you and your team to add your creative genius. In this article we’ll examine common architectures for the connected home and technology considerations to help navigate the IoT.

We all want to be in control of the security of our home and family, and it only takes a fire or burglary to remind ourselves of this need. A number of upstarts and cable operators have introduced products for the connected home that provide fire, security and convenience services. A typical connected home system architecture comprises a number of sensor nodes ranging from simple to complex, a wireless network featuring a gateway to connect to the Internet wirelessly and potentially provide localized system intelligence, and cloud services to connect to mobile devices. Figure 1 shows such a connected home architecture.

Embedded systems designers must consider a number of competing requirements in designing a gateway or sensor nodes, such as processing speed, memory size, regulatory considerations, energy consumption, system latency, connectivity options, system segmentation, security requirements, interoperability, future migration and system cost, to name a few.

SI IoT_Fig1
Figure 1. The Connected Home

The system gateway might be a cable set-top box or a standalone system. See Figure 2 for an example of a typical gateway architecture. The gateway microcontroller (MCU) is most likely based on an ARM Cortex-M or Cortex-A class processor combined with connectivity options such as Ethernet, Wi-Fi, ZigBee and sub-GHz/ISM wireless. Considerations for selecting the optimal MCU include memory size and processing requirements for the communications stacks and gateway services, system latency requirements for “real-time” or offline operation, and connectivity. Considerations for selecting the RF subsystem include local regulations (FCC, ETSI, etc.), whether connection to a broader ecosystem is desired (which requires a standard) or if the system will be self-contained (a proprietary stack can be used), protocol stack requirements, link budget (which translates into RF range) and system cost. Wireless transceiver energy consumption is relevant to the system architecture since it affects sensor node range and battery lifetime.

A “thin” gateway that only passes sensor and environmental data via Ethernet or an RF subsystem to the cloud could suffice with a smaller, less -xpensive Cortex-M class MCU, particularly if the communications stack requirements are kept minimal. The advantage of a thin gateway is that intelligence and interoperability between nodes can be managed by cloud services, but the disadvantage is the potential for roundtrip while waiting for cloud services to process and return command and control data. At the other extreme, a “smart” gateway provides the command and control intelligence onboard and has the advantage of minimal latency and full functionality if the cloud connection is lost. However, smart gateway applications must manage the business logic and must be future-proofed to support system upgrades. Nobody wants to buy a wireless lighting control system today that requires a new gateway tomorrow.

SI IoT_Fig2
Figure 2. Example of Connected Home Gateway Architecture

The basic connected home node might be a door sensor, wireless light or a smoke detector, as shown in Figure 3. The MCU is likely to be a low-energy 8-bit device or a 32-bit ARM Cortex-M class device. Considerations for selecting the optimal MCU include memory and processing requirements for the RF stack and sensor management, energy consumption, device footprint and cost. Considerations for selecting the RF protocol include energy consumption, link budget and cost. Typical wireless connectivity options include a proprietary sub-GHz/ISM stack, ZigBee, Bluetooth or Wi-Fi. Of these options, sub-GHz and ZigBee are the most commonly used protocols for home automation as they provide the energy efficiency, long battery life (typically 3-5 years) and extended range required to locate a sensor node anywhere in a house without the inconvenience of having to change batteries frequently. Bluetooth lacks adequate range for many wireless sensor node applications because it there is no provision for repeaters. The power requirements of Bluetooth are also significantly greater than ZigBee. Wi-Fi requires higher power consumption than ZigBee and sub-GHz and is thus not appropriate for battery-powered applications in which the battery cannot be easily recharged.

For sub-GHz star endpoints or flooding-capable RF stacks and space-constrained applications such as sensor nodes, a small footprint, ultra-low energy 8-bit MCU and RF transceiver, or SoC with integrated MCU and transceiver may offer the most cost-effective solution. For ZigBee mesh networking applications, an SoC with integrated MCU and RF subsystems might be the best option, particularly where PCB area is at a premium. Look for MCU and RF transceiver suppliers who offer low-energy 8-bit and 32-bit Cortex-M MCUs and wireless SoCs along with the development tools to simplify implementing the RF stack requirements.

SI IoT_Fig3
Figure 3. Basic Sensor Node Architecture

The advanced IoT end node might be a smart thermostat, wireless camera or a white goods device such as a washing machine, as shown in Figure 4. The main system MCU is likely to be a 32-bit ARM Cortex-M or Cortex-A class device combined with one or more secondary 32-bit Cortex-M class or 8-bit MCUs used to offload the primary processor, provide features such as capacitive touch sensing, or optimize the energy efficiency of the system by consolidating sensor functions.

Key considerations for selecting the primary MCU include memory and processing requirements for the RF stacks, sensor and system management, and cost. Energy consumption will be of concern for battery-powered-solutions. Considerations for selecting the secondary MCU include integrated features and energy efficiency. Look for MCU suppliers that offer the most energy-friendly 8-bit and 32-bit MCUs. Considerations for selecting the optimal RF connectivity solution include bandwidth, energy consumption link budget and cost, with ZigBee, Bluetooth and Wi-Fi being the most common options. Wi-Fi is the most widely used protocol for bandwidth-intensive applications such as a wireless camera, while ZigBee is ideal for thermostat applications with multiple nodes and lower data rates. Wi-Fi or Bluetooth provide easy connectivity with smart phones and tablets, which end users typically use to control their connected home applications.

SI IoT_Fig4
Figure 4. Advanced Sensor Node Architecture

IoT developers must consider this question when optimizing their end node application’s energy efficiency: “Which is more important for my low-energy application—suspend current or active current?” The answer depends on the active time duty cycle. Some energy-friendly ARM Cortex-M class MCUs can consume as little as 110 µA/MHz in active mode and 900 nA in deep sleep with brown-out detection active, which means suspend and active operation contribute equally at 0.1% duty cycle at 8 MHz operation. Navigating MCU vendor datasheets to compare performance for low-energy applications can be a challenge. Look for MCU suppliers that offer energy estimation and profiling tools and offer excellent suspend and active current performance.

Another frequently asked question concerns the choice of MCU bit size for IoT applications: “When should I consider using an 8-bit MCU instead of a 32-bit solution for my end node application? Why not migrate to a modern 32-bit MCU based on an ARM Cortex-M architecture that supports expanded memory requirements, native 32-bit math and advanced peripherals?”

For many performance-intensive IoT applications, the 32-bit choice is of course the right answer, particularly where portability and future platform reuse are key concerns. However, for end-node applications where the goal is to fit in the absolute smallest footprint, run a lightweight RF stack or offload computation tasks from the main MCU, a streamlined and highly optimized 8-bit solution is often the right answer. A common misconception of an 8-bit architecture is that it suffers from low code density. In reality, this is true only when attempting 16- or 32-bit math. Control applications such as those found in offloading the main processor do not suffer from low density, and in fact, because 8-bit MCUs have very little overhead code, overall code density for control-type functions is higher than equivalent functions implemented on 32-bit MCUs.

Another common misconception is that 32-bit MCU pricing is comparable to 8-bit options. Developers will hear this from MCU suppliers that are no longer investing in an 8-bit portfolio or competitive in the 8-bit market. The reality is that the 32-bit architecture and peripherals are significantly larger in gate count than 8-bit architectures and consume more silicon area when compared to 8-bit solutions in the same process geometry. Moving to a smaller process geometry shrinks the digital portion (which is about half of a typical MCU) and increases the system cost. When considering a comprehensive IoT solution provider, look for MCU vendors that are actively investing in both 8-bit and 32-bit MCU portfolios, and you will find the most flexible MCU options, the best technical solutions and the best pricing.

The IoT is the vision of a road to a hyper-connected world in which end users have dramatically expanded knowledge and control of their environments—at home, at work and on the road wherever they may be. Elegantly designed and innovative IoT connected devices, apps and cloud services will be most successful in driving the IoT revolution. IoT end nodes and gateways that offer the best combination of energy-efficiency, performance, cost effectiveness and appealing features—regardless of MCU bit size—will be in the driver’s seat in the race to our IoT future. Are you ready?


SI Greg HodgsonGreg Hodgson is director of marketing for Silicon Labs’ microcontrollers group. He joined Silicon Labs in 2004 and has held senior roles in applications and systems engineering focusing on broadcast audio and in marketing focusing on 8-bit and 32-bit microcontroller products. Prior to joining Silicon Labs he was staff engineer at National Instruments focusing on design of audio analyzer equipment. Mr. Hodgson holds a BSECE from Ohio State University.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis

Tags: , ,