Ten strategies to minimize cross-platform design complexity in an IoT world

November 14, 2016 // By Stefan Ingenhaag, Renesas Electronics Europe
Every engineering project demands tradeoffs among its many specifications, which can be classified into three broad factors: performance, power consumption, and price. Each project has a “sweet spot” somewhere within a triangle with those three factors at its corners, but with different relative weightings depending on the product, market, and timing.

The potential growth in applications related to the Internet of Things (IoT) is providing new opportunities for vendors and their design teams, but it is also adding to their already long list of hardware and software engineering challenges. The hardware and software are intimately related, and together create a platform that will require strategies for minimizing cross-platform design complexity. Some of these strategies include:


1. Limiting sensor and transducer I/O

Decide up-front if your I/O needs will have a fixed or limited number and type, or if they need to be expandable in count and flexible in type. The decision affects your options in MCU and peripheral selection. It’s especially critical when the I/O consists of more than just simple, low-voltage digital points, but instead may include temperature sensors, motors, and even the communications lines, with both serial and parallel formats.


2. Using an external, certified RF module

A module which is separate from the core application processor makes the most sense in many cases. While a single-chip, highly integrated solution may seem attractive in terms of board space, power, and cost, it means that changes or extensions in wireless protocol, required range, and even regulatory requirements will mandate a major redesign, or perhaps a new MCU and RF link-related firmware. Even if the coding part is straightforward (unlikely), the MCU may be inadequate for the new requirements and need to be upgraded as well, which adds to development time and risk.


3. Trading power for performance

Understand clearly where your proposed MCU selection fits in the power versus performance matrix. As you move up along the curve of required performance, there will be points where you cross thresholds and have to step up to larger MCUs that consume more power. There’s a complementary issue as well: as you slide down the curve and need fewer resources, you will be able to consider smaller, cheaper MCUs which needs less power. Just be sure the specific MCU you choose supports a sophisticated range of speed versus functionality and power modes, so you can optimize operational sequences for lowest overall energy consumption, yet handle the required, power-intensive operational spurts.

Design category: