Bending Micrium OS to IoT
A year ago, Silicon Labs acquired Micrium, a supplier of real-time operating system software. The purchase of Micrium was motivated by the need to support Silicon Labs’ customers who want an RTOS for their IoT apps.
However, more important, owning Micrium empowers Silicon Labs to “bend the kernel of Micrium RTOS for connected IoT applications,” explained Cooley, so that the RTOS can support dynamic radio schedulers, while meeting real-time requirements in wireless protocol stacks. “Our long-term strategy is to make Micrium an IoT OS, and that is paying off now,” he added.
IHS Markit analyst Ratliff explained that the dynamic multi-protocol radio scheduler is very low level in the software stack — just above the OS, but under the connectivity stack. “At this low level, it’s very important to have essentially unrestricted access to the OS for best performance,” he noted.
MicriumOS and the Radio Scheduler coordinate timing between Bluetooth and Zigbee stacks (Silicon Labs)
In short, he said, “You can only do this by owning the OS or having an extremely good partnership with the OS vendor. You not only need low-level OS support, but you also want to make sure that your solution doesn’t break when the OS version is revised. If you don’t own the platform you’re building on, you are at the mercy of someone else.”
Ratliff added, “This [dynamic multi-protocol scheduler software] could be ported to another OS, but Silicon Labs told me that they have no plans to do so.”
Cooley added that by owning its own RTOS, Silicon Labs won’t face a dreaded future in which it has to port an IoT app to five operating systems, every time a new one pops up. What will this software buy us?
First, “We are delivering an IoT solution with one antenna, one software package and one CPU,” said Cooley.
Second, “We are meeting IoT users’ desire to interface with mobile phones.” With dynamic multi-protocol software, IoT device users can now “commission, update, control and monitor Zigbee mesh networks directly over Bluetooth with smartphone apps,” according to Silicon Labs.
Third, with the dynamic multi-protocol software inside Silicon Labs’ IoT chips, IoT applications such as lighting, home automation and security can be controlled by mobile devices “without having to go to Internet,” Cooley added. Brief history of IoT chips
IoT chips have already seen some notable evolutions over the past several years. Here’s how Ratliff sees “a couple of stages of MCU integration in connectivity chips.”
It all started some five years ago when small MCUs (like ARM Cortex M0) began to invade the transceiver, allowing the connectivity software stack to run on-chip — a single chip connectivity solution. “This allowed semiconductor vendors to qualify standalone software stacks and distribute as tested object code rather than source code that had to be integrated in a larger external MCU that also ran the application,” Ratliff explained. This was considered progress, because “abstracting the connectivity function in the design just made life easier for the OEM — one less thing to worry about,” he explained.
The second phase of MCU integration started 2-3 years ago when the connectivity MCU got powerful enough (like Cortex M4) to run application software in addition to the stack. “While this worked against the concept of abstracting the connectivity function, it has still become popular because it has often allowed OEMs to eliminate an external MCU, saving space and cost,” said Ratliff.
A good example is Dialog Semiconductor winning the original Xiaomi Mi Band socket several years ago, he noted. “Xiaomi wanted to make a fitness band with incredibly low cost, but with most of the functionality of the Fitbit. They chose a Dialog BLE chip — the DA14580 — and it ran the stack and the application code, eliminating an external MCU.” He added, “The DA14580 wasn’t even designed to run more than the stack, but Dialog and Xiaomi pared down the code until they made it work. This was a major factor in enabling the $15 price point that was their goal.”
Ratliff said that integrated connectivity plus MCU for the stack has become the norm, especially for BLE and multi-protocol devices. For most low-power wireless protocols, transceivers without an MCU for the stack are only used in legacy designs.
The next step up, Ratliff noted, is “connectivity with an MCU capable of running stack plus app.” Although this has gained popularity, “this is still far from ubiquity,” he noted.
Next page: Late to BLE party?