feature article
Subscribe Now

Easier Gadget Wireless

One for Coding; One for No Coding

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

One thought on “Easier Gadget Wireless”

Leave a Reply

featured blogs
Dec 19, 2024
Explore Concurrent Multiprotocol and examine the distinctions between CMP single channel, CMP with concurrent listening, and CMP with BLE Dynamic Multiprotocol....
Dec 24, 2024
Going to the supermarket? If so, you need to watch this video on 'Why the Other Line is Likely to Move Faster' (a.k.a. 'Queuing Theory for the Holiday Season')....

Libby's Lab

Libby's Lab - Scopes Out Littelfuse's SRP1 Solid State Relays

Sponsored by Mouser Electronics and Littelfuse

In this episode of Libby's Lab, Libby and Demo investigate quiet, reliable SRP1 solid state relays from Littelfuse availavble on Mouser.com. These multi-purpose relays give engineers a reliable, high-endurance alternative to mechanical relays that provide silent operation and superior uptime.

Click here for more information about Littelfuse SRP1 High-Endurance Solid-State Relays

featured chalk talk

High Power Charging Inlets
All major truck and bus OEMs will be launching electric vehicle platforms within the next few years and in order to keep pace with on-highway and off-highway EV innovation, our charging inlets must also provide the voltage, current and charging requirements needed for these vehicles. In this episode of Chalk Talk, Amelia Dalton and Drew Reetz from TE Connectivity investigate charging inlet design considerations for the next generation of industrial and commercial transportation, the differences between AC only charging and fast charge and high power charging inlets, and the benefits that TE Connectivity’s ICT high power charging inlets bring to these kinds of designs.
Aug 30, 2024
36,124 views