Ten strategies to minimize cross-platform design complexity in an IoT world: Page 2 of 3

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.

4. Simplify your security

Some processors have dedicated, hardware embedded features that will make some aspects of security automatic and independent of any application software or even the chosen RTOS; these may accelerate and simplify your security challenges. Even better, if that same embedded security function is available on all MCUs on your shortlist, this significant part of the IoT challenge can be taken off the “to do” list regardless of the specific processor selected.

 

5. Standardize your system

Standardizing on a low-power 8/16-bit MCU and then implementing different memory sizes (on-chip or external) as requirements move both up and down the size/performance scale; OR go with a single, larger 32-bit MCU and accept that there will be unused capacity in lower-end applications, but with the benefit of code and driver consistency, plus simplified BOM and test procedures.

 

6. Operating system selection

In some cases, a simple, low-cost single-thread OS will be sufficient, but for many projects, you’ll need a real-time OS (RTOS). For either choice, you need to assess the OS scalability and availability of small-, medium-, and large-footprint versions. Be realistic about the size of that smallest version, and its corresponding capabilities – you don’t want to “hit a wall” on OS capability as your project is at the 80% completion point.

 

7. Upgrading hardware versus software

At key points along the curve of software resources required to complete added tasks (development time, processor resources), you will have to decide between adding a peripheral IC to offload the fully committed MCU, or choosing a faster MCU. Be prepared for this decision point, by analyzing when a more-powerful MCU lets you pull a hardware task back into software, thus saving component cost, footprint, and power (in principle) but with a likely penalty of longer development and debug time.

 

8. Choosting your connectivity protocol carefully

Look at a “lighter” IoT-optimized protocol rather than the client/server HTTP-based Internet browser model. This will reduce stack and processing requirements by a factor of two or more, yet allow you to handle a variety of IoT devices and their peripherals. At the same time, consider what will happen when the connectivity requirements (protocol, speed, integrity) increase, as the market becomes more demanding.

Design category: