Silicon Labs Bends Micrium RTOS to IoT

　　It’s hard to argue with anyone who insists that the Internet of Things (IoT) still has a long way to go, if only because no application-level standards exist to ease interoperability among various IoT devices. An issue possibly even more serious is sloppy IoT security, thrown in as an afterthought more often than not.

　　But the IoT industry isn’t standing still. Chip vendors are making progress in connectivity, an integral part of the IoT story. Since neither homes nor commercial buildings are built on a single wireless network, IoT chips with built-in multi-protocol support are fast becoming mainstream.

　　By launching Monday (Nov. 6) what the company describes as “dynamic multi-protocol software” for its Wireless Gecko SoC and module portfolio, Silicon Labs hopes to stand out among a growing list of IoT chip vendors with multi-protocol capability already designed into their hardware. Silicon Labs claims its new software is unique, because it enables “IoT devices to dynamically connect to Zigbee and Bluetooth Low Energy ecosystems at the same time,” as put it by Daniel Cooley, senior vice president and general manager of IoT products at Silicon Labs.

　　Dynamic multi-protocol

　　Lee Ratliff, senior principal analyst for connectivity and IoT, technology, media & telecom at IHS Markit, said, “Off the top of my head, I know that Nordic, TI, NXP, Qorvo, and ON Semiconductor have multi-protocol capability in hardware.”

　　However, dynamic switching is not prevalent in their solutions. Ratliff told us, “All multi-protocol products and demos I’ve seen have been either programmed (one time switch after device provisioning on the network) or switched (multiple switches between protocols during normal operation, but not real-time dynamic).”

　　A variety of IoT use-case scenarios serve to explain the need for dynamic multi-protocol operations. Dynamic time slicing between networks becomes critical, for example, when a primary Thread network must periodically transmit Bluetooth Low Energy (BLE) beacon. This also applies when a primary Zigbee network must switch to BLE if an eligible device is present, or when IoT devices have to listen on one network and transmit on another for network translation.

　　Ratliff said, “Coordinating dynamic switching in software is difficult, even if your hardware is already capable. That’s why this Silicon Labs announcement is important.” Ratliff added that Silicon Labs “has done the hard software work to ensure that dynamic switching is easy and reliable without the OEM needing to write all the low-level radio scheduler software.”

　　Silicon Labs’ Cooley noted, “Think about a wireless network like Zigbee… a low-duty cycle radio network that doesn’t really need to be ‘on’ all the time. In contrast, BLE is an unforgiving wireless network that must be maintained all the time.” A “dynamic multi-protocol radio scheduler” comes into play for time-slicing among two different wireless networks, all the while maintaining multiple radio protocols.

　　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.

　　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 DA14580wasn’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.

　　More low-power wireless connectivity vendors have added this option, often along with multi-protocol support, said Ratliff. Examples include Nordic Semiconductor with its nRF52 family, TI with CC26xx, Qorvo with GP695, ON Semiconductor RSL10, Cypress with BCM207xx chips and Silicon Labs’ Gecko products.

　　These are obvious examples, he said, “because they have upgraded to Cortex M3 or M4.”  Ratliff added that many Cortex M0 chips (such as the Dialog DA14681) are also capable of running application code in addition to the stack. “There’s a spectrum of solutions with varying levels of support for application code.”

　　As Silicon Labs sees the market’s evolution, the newest phase — and where it seeks differentiation — lies in RTOS. Do you have an RTOS kernel capable of dynamic multi-protocol scheduling? Or, do you continue to write the stack to the bare metal? Are you forced to meet dynamic multi-protocol scheduling demands by using a two-chip solution consisting of a host MCU and a connectivity SoC?

　　By owning Micrium RTOS, Cooley said, “We think we can meet customers’ needs faster” by running Silicon Labs’ connectivity code and customers’ application code on Silicon Labs’ integrated “connectivity plus app” IoT chips.

　　Late to the BLE party?

　　Ratliff described Silicon Labs’ two strengths as “experience and software.” They are intertwined, he said. Silicon Labs has “a deep bench of engineering experience” with more than 15 years’ experience with low-power and embedded connectivity in Zigbee.

　　On the software side, Silicon Labs has its own, “industry leading Zigbee and Thread stacks,” he said. Silicon Labs has demonstrated its prominance “right in the middle of the creation of both of those standards.”

　　The reality in the IoT market today is that many other connectivity vendors “rely on third-party or open-source code, requiring their customers to piece together a software solution and perform extensive testing and qualification to make sure it all works together,” Ratliff observed. “Silicon Labs can offer a pre-qualified solution that can reduce risk and decrease time to market. Equally important as their run-time code is their portfolio of software dev tools, which have been honed over many years,” he added.

　　He said, however, that Silicon Labs’ weakness lies in “their late time-to-market with a BLE solution.”

　　Noting that Silicon Labs is on its first generation of BLE chips, the IHS analyst said, “They’ve designed what I suspect is an over-engineered set of chips that can be configured to address any application.” Calling such a move “typical for any vendor’s first-gen chips” in hopes of gaining share, he cautioned, “if the share doesn’t gain, management may lose interest in funding more R&D.”

　　Availability

　　According to Silicon Labs, the new multiprotocol software is available now to customers using Silicon Labs’ EFR32MG12 and EFR32MG13 Wireless Gecko SoCs and associated modules. “I don’t want to say it’s free, but, yes, the software package comes without extra charge,” Cooley said.