Editor's Note: This article was originally published in the August edition of ECN.

Converting traditional consumer and commercial products into wireless-enabled, “smart” products is one of the biggest trends shaping the pipeline of projects being assigned to electronic design engineers today—with very good reason. Regardless of whether your company makes toasters or oil well drills or home security systems or children’s toys, there is big money to be made in offering customers a wirelessly-enabled product line that has all the bells and whistles that come with smartphone controllability, real-time data and other “gee whiz” features.

That is leading to an avalanche of high-priority projects for electronic design engineers related to the Internet of Things (IoT) and Machine-to-Machine (M2M) capabilities. Regardless of whether it is labeled as IoT, M2M, “wirelessly-enabled,” or just “smart,” these re-design projects are coming fast and furious at electronic design engineers in industries across the spectrum—all with aggressive timelines driven by companies’ desire to improve user experience, respond to customer needs, and capture market share.

This probably isn’t news to most readers of ECN. For many engineers, that flood of product re-designs isn’t on the distant horizon. It’s a reality today, and it is creating major challenges because making a traditional product wirelessly-enabled isn’t as easy as folks up the food chain might imagine. It’s not simply a matter of “slapping an antenna” on the product and “getting one of those iPhone app thingies” to run it. It’s a lot more complicated. But there are some key ways that engineers can shorten the development cycle and also get an elegant final design—which is always a bonus.

Faster and more elegant
One key way to get your connected product design project across the finish line faster is to take advantage of an IoT Platform-as-a-Service (PaaS), which allows you to offload a significant amount of work that would ordinarily go into the product itself, placing it instead in the cloud with pre-built infrastructure and software. Taking advantage of an existing platform saves time, minimizes risks, reduces the drain on internal resources, and gives the product itself far fewer “moving parts” in terms of its wireless connectivity.

Utilizing the cloud is a topic for another piece, though. This article focuses on another huge time saver and simplifier for your connected product project: Avoiding the use of AT Command sets for addressing a number of key functions such as Wi-Fi control. Most product re-designs to add wireless connectivity will look to utilizing a product’s existing MCU as a host controller of the RF module to minimize the design efforts—rather than replacing the MCU and making the redesign much more complicated in the process—and for many engineers their comfort-level will nudge them towards an AT Command set approach to that serial communication.

AT Command sets were first utilized in the early 1980s as a creative solution to the challenge of transmitting commands between embedded systems and communications devices that act as a go-between with the world at large. AT Command sets have been popular ever since because they utilize very small data packets, allowing a lot of work to be done with very small batches of instructions and data. In the 1980s, that was really, really important, given the computing power and memory constraints and data processing capabilities that systems had at the time. Anyone who had a Commodore 64 or other early PC can attest to that. For that era, AT Commands were an elegant solution that worked around the miniscule memory and single serial ports that were the apex of technology at the time, allowing engineers to communicate sophisticated commands with very short ASCII strings that started with the iconic two-character AT script that gives AT Commands their name.


More than 30 years later, AT Commands remain very common in product design, and they are often the immediate strategy that engineers think of when they are working on a wirelessly-enabled product and need to facilitate serial communications between an MCU and key components like a Wi-Fi module. AT Commands seem like the natural solution, but the reality is that they introduce unnecessary complexities, create delays, and are poorly suited to the specific functionality that IoT/M2M products today are aiming to deliver.

The limitations of AT commands
AT Commands are not an ideal approach for IoT/M2M projects because of the inherent limitations of traditional ASCII-based command for supporting the communication of data to and from the device itself out to the cloud, where it can then be accessed and interacted with by users. AT Commands were created in a pre-Internet world, which means that designers need to do some clever things in order to write AT Commands in a way that successfully, reliably communicates data from the device, to the web-based language that a Wi-Fi network uses, and on to the cloud where it can then be accessed anytime/anywhere by the user.

Yes, it can be done. But should it be? Is it worth the investment in time and brain power to figure out that puzzle? Or is there a way to bypass those ASCII-to-Wi-Fi hurdles so that there is a simpler, cleaner, more elegant solution for getting data out of the device and out to users? There is and it results in a stronger, more flexible end product, which is why I hope this article encourages ECN readers to think twice before taking the AT Command approach. That alternative approach is to use a human-readable, object-oriented approach to embedded code in an IoT/M2M design product, which is much better suited to the task of creating that product-to-the-cloud link. Another way to think of it is, if the design problem is not just to get the data from the MCU to the Wi-Fi module but to get that data up to the cloud, newer innovative software can be leveraged that abstracts all the minutiae of facilitating Wi-Fi through AT Commands for the developer.

With a minimal increase in on-chip memory, a design team can utilize a much more modern and much better-suited approach to creating the instructions and communication that is needed in a product that is enabled with Wi-Fi connectivity. By using a formats such as JSON and XML, design teams can dramatically reduce the timeline for a project while also minimizing the programming headaches that come from traditional AT Commands. The key is that these more modern, object-based languages are compatible across each of the platforms that a connected product utilizes: the embedded technology inside the product itself, the cloud server that the product communicates with via Wi-Fi and the web/smartphone app that the end user utilizes to interface with the product.

The scenic route should be the path less taken
JSON-RPC (Remote Procedure Call) is an example of a human-readable solution that is well suited to IoT/M2M design projects. JSON-RPC is inherently an object-oriented approach to data communication. Rather than having one command per parameter, groups of related parameters are supplied to function calls. The result is a much simpler, cleaner and more intuitive interface for the developer. In addition to the benefits of human readability, JSON-RPC integrates seamlessly into existing server infrastructures and web services platforms. This provides crucial benefits for connected products with remote data-sharing requirements, and it does so in a way that would be nearly impossible with traditional AT Commands.

There is another reason why this alternative to AT Commands makes sense, and it is not a trivial one. When a company is working on a cloud-connected design project that brings together a wirelessly-enabled product, cloud servers and mobile apps into an integrated solution, using JSON-RPC creates a common ground that the web and app developers will already be familiar with. This is significant because not having that common ground can cause a development project to immediately bog down when it comes time to create the mobile apps and web-based user interface. An alternative like JSON means everyone will be speaking the same language, literally, when that phase of the project arrives.

Does this mean that design team should have their team members run out and sign up for JSON certification classes? Thankfully, no. That is because there are pre-built software platforms built on JSON and XML that are ready to plug into this aspect of IoT/M2M design projects, alleviating the need for designers to tackle this themselves and giving designers a potent alternative to traditional AT Commands for creating a link between a product’s existing microcontroller and the new wireless module.

Every engineer I have ever worked with believes in the power of design elegance. Oftentimes, the simplest design with the fewest moving parts and the least complexity ends up being the most effective, and the most reliable. At one time ASCII-based AT Commands were the most elegant solution to the design challenges of that day and they still are relevant for many tasks, but IoT/M2M projects have requirements that take the simplicity of AT Commands and twist them into unrecognizable shapes that are neither elegant nor effective. AT Commands still have their place, but a human-readable, object-based strategy—especially one that utilizes the pre-built platforms that are available for design projects—will remove one of the major bottlenecks for your IoT project. Sometimes the scenic route makes sense, but for these projects this alternative route will get you much faster and much more reliably.