Implementing a processor-independent, battery-powered wireless mesh network

This can cause problems with conventional wireless implementations in which (a) the stack is closely tied to a particular microcontroller and (b) creating the wireless applications requires extensive C/C++ programming and embedded expertise.

This article describes an alternative approach that mitigates these problems. By providing the stack with an integrated Hardware Abstraction Layer (HAL), the body of the stack is isolated from any low-level "pin-twiddling" operations.

Also, by incorporating a Python virtual machine in the stack, applications can be quickly and easily created in the Python scripting language and (transparently to the user) compiled into machine-independent "byte code" that will run on any processor and that can be downloaded "over-the-air" into the wireless node(s).

Looking for an alternative approach
The world is currently seeing an exponential growth in the use of wireless networks for monitoring and control in consumer, commercial, industrial, and government markets. Uses range from building automation (lighting, heating, A/C) to industrial control and machine communication, to medical monitoring, to security applications, to home automation.

In many cases, it is required to add wireless capability to existing embedded systems. Often, in order to minimize costs, it is necessary to run the wireless software stack (and associated applications) on the same processor that drives the main system.

This can cause problems with conventional wireless implementations in which (a) the stack is closely tied to a particular microcontroller and (b) creating the wireless applications requires extensive C/C++ programming and embedded expertise.

This article describes an alternative approach that mitigates these problems. By providing the stack with an integrated Hardware Abstraction Layer (HAL), the body of the stack is isolated from any low-level "pin-twiddling" operations.

Also, by incorporating a Python virtual machine in the stack, applications can be quickly and easily created in the Python scripting language and (transparently to the user) compiled into machine-independent "byte code" that will run on any processor and that can be downloaded "over-the-air" into the wireless node(s).

What do you actually want to do?
A few years ago, the company for which I am VP of Engineering realized that the embedded world was poised to go wireless and that there was going to be a tremendous market in wireless monitoring and control network applications. At that time, the company, Synapse, was focused on sensor applications, so expanding our mission " and renaming ourselves to Synapse Wireless " was an obvious evolution.

We quickly realized that there were a variety of implementation scenarios depending on each customer's unique requirements. In order to provide a simple example, let's assume an existing system that includes a microcontroller that is used to monitor one or more sensors, accept user input, drive a display, and output signals via a wired connection (using RS232, for example) as illustrated in Figure 1 below.

Figure 1. Existing system with a wired connection to the outside world.

Assuming the creators of this system wish to augment their product with wireless capabilities, one scenario would be to simply modify their existing board to accept an off-the-shelf plug-in wireless module as illustrated in Figure 2 below.

Figure 2. Adding a plug-in module to provide a wireless connection to the outside world.

In addition to an on-board microcontroller (with timers, A/D converters etc.) and a radio frequency (RF) chip, the wireless module would also include some non-volatile memory containing the wireless protocol stack and user-created wireless applications.

Alternatively, high-volume and/or price-sensitive projects may require that the wireless functionality is implemented directly onto the motherboard as illustrated in Figure 3 below..

Figure 3. Running the wireless stack on the on-board microcontroller.

In this case, rather than having two processors (the microcontroller for the main system and the microcontroller on the wireless module), the RF PHY chip (along with any related RF components) would be mounted directly on the main circuit board, while the wireless stack and application software would be executed on the same microcontroller used to control the rest of the system.

Once a product has been equipped with wireless capability, the next step is to create and deploy any wireless applications; that is, the programs that monitor the sensor inputs, make decisions, and drive the actuator outputs that interface to the real-world. These applications also instigate the wireless transmission of commands and data (via requests to the stack) and respond to incoming commands and data (received and processed by the stack).

So, from our perspective, the problem was multifaceted. With regard to the creators of embedded systems, we wanted to be in a position to provide (a) off-the-shelf wireless modules and (b) a processor-independent wireless stack that could be easily ported onto existing microcontrollers. Meanwhile, in the case of the end users, we wanted to provide an environment that allowed applications to be created, deployed, and debugged quickly and efficiently.

Surely this wasn't too much to ask ... was it?