So you’re going to add wireless capabilities to your WidgetMaster-Plus, eh? You did all that work getting the widgety parts working, so now all you need is to slap on an antenna and a wireless thingymawhatcher and it’s out the door, right?

Yeah, well, maybe so, maybe no. There are two phases to getting this done. The first is simply getting the wireless functionality to work, which itself has two aspects: the hardware radio and the software stacks. Either of which you might do yourself or find something off-the-shelf. Our focus today will be the software.

Once you’ve done that, you have the second piece of the task: getting the dang thing certified. Ayla Networks says that it can take a year to get something out the door, including certification.

Of course, stacks are a dime a dozen – cheaper if you go open source. Cheaper from an initial-cash-out perspective, that is. But then you have to adapt them to your system. That’s where the cost – and time – come in.

Well, today we’re going to talk about two different approaches to this problem: one from Ayla Networks and one from Silicon Labs. Both have the same goal: getting your wireless functionality out the door faster. The first approach is for companies rolling their own functionality; the second is for those who want to go with no rolling.

Bear in mind, of course, that “wireless” isn’t one thing. It’s a bunch of things: WiFi, Bluetooth, cellular (of many flavors), Zigbee, Thread, and even Z-Wave. So which solution you pick may well depend on which wireless you are trying to implement. The solutions we’ll discuss today focus on the big ones: cellular, WiFi, and Bluetooth.

Cut the Time in Half

Ayla Networks was the first IoT company we talked about way back when. Ayla brings a couple of capabilities to this problem for those doing their own thing with either WiFi or cellular. Why would you code-your-own when Ayla already makes modules that are prêt-à-porter? They list various reasons:

• You’re modifying an existing product, so you’re not redoing the whole thing.
• You’re using hardware that Ayla doesn’t support directly. You may have special considerations (price, existing business relationships, etc.) underlying that choice.
• You want more control.
• You want specific functionality – and only that functionality. Nothing extra or unused.

They’re also positioning this for use by module makers who can then sell their canned functionality to their customers. It is, however, an approach that’s appropriate for a team that has experience doing this and that can program in C.

The first bit that Ayla has announced is their Portable Agent. This is code and libraries that can be leveraged to cut development and certification time down from a year to six months for an experienced team.

Ayla illustrates their approach below. The orange parts are what you would focus on; the green parts are what Ayla provides to speed the process up. Let’s walk through this.

(Image courtesy Ayla Networks)

The APP layer is, of course, your application. You still have to do that bit; sorry. The ADA layer is the Ayla Device Agent. It’s available as a library element or as source code. The Ayla Library contains a variety of utilities written to be platform-independent. This includes code necessary for interacting with Ayla’s cloud resources.

Those three elements all interact with the Adapter Layer (AL), and this is where you spend much of your implementation time. You’ve got a specific platform, which means you need platform-specific code. And yet this whole agent thing is platform-independent. So the AL is where you take all your specific code and wrap it in an API that Ayla specifies so that it can interact with the ADA and the Library. There are interfaces for threads, mutexes, memory access, network functions, and security functions, to list some examples.

Which Mobile?

The other thing they’re tackling is the challenge of doing one application that can run on multiple different mobile platforms. Specifically, iOS and Android. Ayla suggests that it’s not easy to maintain a single code base for the app and then adapt it for the different platforms in an easily manageable way.

So they have come up with a way to do a single “skeleton” application, but then personalize it for its platform at both build and run times. The end game is a JSON file that contains the customizing data for the code. So you have a single application with indirection and dangling hooks, and then, at run time, the JSON data is read and implements late binding of the code appropriate to the platform.

This late-binding approach doesn’t fit so well with the build process, which is why they intervene there as well to manage the indirection and the unbound calls. They also eliminate library objects that aren’t used, in order to unclutter things.

The image below illustrates this adaptation – although, at least as I interpret it, it suggests that a single JSON file can run on either platform – making it look like a build-time thing. Instead, there’s really a single app version, with a different JSON adaptation file for each one (kind of the reverse of what’s shown). The “skeleton app” is the same on both platforms.

(Image courtesy Ayla Networks)

Move the Stack

Meanwhile, Silicon Labs announced a solution for WiFi and Bluetooth that, at first glance, looks just like another couple of modules. But there’s a critical difference: their modules include the stack in the package.

They tout this as a “zero programming” approach, meaning it’s good-to-go with no coding.

They illustrate this basic distinction as follows. While anyone buying a module has to implement a stack (which may be provided by the module-maker), that stack is typically run in a host processor, not in the module. Which means adapting the stack to that processor. And it means selecting a microcontroller that can handle the stack – which may be more microcontroller than you otherwise would need.

(Click to expand. Image courtesy Silicon Labs)

By moving the stack into the module, it’s complete in the shipped product, needing no further adaptation. You can select your microcontroller based on your other application requirements only. This clearly is well suited to a different audience than that for which the Ayla solution is intended. As they tell it, the story isn’t about more streamlined coding; it’s about no coding.

They’ve got a couple of versions of each module, although they’re not quite parallel.

(Image courtesy Silicon Labs)

For Bluetooth, they have PCB-module and system-in-package (SiP) options. Both contain the antenna. On the WiFi side, there’s a module with the antenna, and then there’s a chip-only version that’s smaller but has no antenna.

Both run atop what they call their GeckoOS system. They make most of the GeckoOS source code available – except for the topmost layer. But they say that it’s not written in a way that makes it easy to port or to learn how things are done. They say that it’s optimized production code, so you have to keep that in mind while wandering through it.

Finally, one benefit that Silicon Labs is touting with their solution is that they own all the bits. They own the hardware chips; they own the stack; they own the module. So, if there’s a support question, there’s no finger-pointing between, say, module-maker and chip-maker. The burden falls entirely on them – and they’re ok with that.

More info:

Ayla Networks

Silicon Labs’ new modules