Designing Wi-Fi connectivity into your embedded "Internet thing" -

Designing Wi-Fi connectivity into your embedded “Internet thing”


In this Product How-To, Redpine Signals' Narasimhan Venkatesh provides some basic guidelines to consider when adding Wi-Fi connectivity to an embedded design and how the development process can be simplified using a combination of a Cypress PSoC and Redpine-supplied components, including its Wi-Fi Expansion Board kit.

Embedded systems for a large variety of applications–including appliances, automation systems, medical devices, entertainment systems, and energy management–today already use or can potentially use a wireless interface.

And just like using an available wired connectivity mechanism, they also can choose from a number of available wireless systems. Zigbee, Bluetooth and proprietary wireless mechanisms have been used in numerous deployments, but there is a growing trend toward standard IP-based 802.11

Wireless LAN, or Wi-Fi as it is also known, as the primary wireless interface in embedded systems. This has not happened as a natural evolution–rather there has been a concerted effort from manufacturers of Wi-Fi devices, and from the Wi-Fi Alliance, in enabling ease of integration of Wi-Fi in embedded environments.

In this article we look at what defines ease of integration of Wi-Fi and how embedded-system designers can easily build systems with Wi-Fi connectivity. We examine hardware and software integration as well as the optimization of Wi-Fi parameters for robust and energy-efficient connectivity for these applications.

Building special purpose Internet “things”
Embedded devices are built for a specific purpose and are, by definition, based on a microcontroller as the core functional block interfaced to multiple peripheral modules providing specialized functionality with limited memory resources. These devices often need to communicate with external monitoring or control systems, and when this communication is based on the universal TCP/IP mechanism, they form a part of the rapidly growing ‘Internet of Things.’

Whatever the application of an embedded device may be, the development of the device can be complex. Hardware functionality, software procedures and system-level considerations would all have to be optimally handled. Microcontroller vendors, therefore, spend much effort in creating development or evaluation kits that greatly ease the software and hardware integration efforts.

The possibility of having Wi-Fi connectivity in an embedded system enables a plethora of new applications the system can address. However, since Wi-Fi was created to provide high speed data connectivity for networking market to start with, integration such technology into embedded devices poses many challenges.  

Wi-Fi integration into embedded devices is a fairly recent trend; designers have to face a number of new considerations that involve hardware and software, as well as system-level aspects such as regulatory certification.
Hardware integration
Hardware integration aspects include size, operating voltage, selection of supporting components, regulatory requirements, and calibration, among others. Due to all these considerations, the most common method of adding WLAN connectivity into an embedded system is through the integration of a self-contained WLAN module or a highly integrated chip. Figure 1 below shows the main components of the Wi-Fi subsystem, and integrated as a chip or module.

Click on image to enlarge.

Figure 1.   Components of a Wi-Fi subsystem

A typical WLAN hardware implementation uses several voltages and often includes power management logic to reduce power consumption. Ease-of-integration demands that the module be supplied with a single, standard voltage.

A power management unit internal to the module generates the required voltages efficiently–often employing one or more DC-DC switching converters followed by low dropout linear regulators. In addition, the power management unit handles the fine-grained control of individual, internal supply paths used to power sections of the device, enabling maximum power savings through the selective switching on or off of portions of the device based on the needs of the operation profile over time.

The WLAN device also requires a number of clocks and reference frequency signals for operation. The RF transceiver contains a frequency synthesizer that uses a stable frequency reference that adheres to the requirements of the standard–a frequency accuracy of 20 ppm or better.

The digital baseband (BBP) and MAC blocks use clocks of various frequencies–the BBP uses clocks that are multiples of 40 MHz and 44 MHz related to the standard way of constructing the transmitted OFDM or DSSS/CCK waveforms. Again, for ease of integration, it would be ideal to have a single frequency reference fed into the module, and for the module to use one or more PLLs to generate the other required clock frequencies, and for the module to also use this reference in its frequency synthesizer.

Minimizing battery drain is a chief requirement of portable or mobile embedded systems—the focus here is on the consumption of energy rather than power. Therefore, apart from ensuring that each operational mode draws the least possible power, it is also important to have minimal time spent in high power states.

Embedded Wi-Fi systems make generous use of WLAN protocol defined power save modes where the system can go to a low power state not supporting transmission or reception, and waking up at periodic intervals to check for pending packets to transmit or receive. During the sleep or idle period between these waking-up events, the WLAN module turns off power to a majority of internal blocks.

Although WLAN uses unlicensed spectrum, its actual transmit characteristics are restricted by several regulatory requirements–defined, for example, in the US by the Federal Communications Commission (FCC).

These include the channels or frequencies that can be used, the maximum power that can be transmitted in those channels, and the characteristics of the transmitted spectrum. The FCC specifies different sets of requirements for intentional and unintentional radiators.

Since a WLAN device is an intentional radiator, any system integrating WLAN functionality would need to be tested for adhering to the requirements of intentional radiators. Providing a fully FCC certified enables system designer to release the product to market quickly and eliminates the effort and time needed to get such regulatory certifications.

Also, as a result of regulatory requirements, which are different in various geographical regions, there is a need to ensure that the actual power transmitted by a WLAN node is controlled within the accepted bounds.

Since the actual power transmitted for a given setting may vary from device to device, a calibration scheme would need to be employed. Self-contained WLAN modules are usually calibrated during manufacture, and the software controlling the device would use the calibration data during normal operation. Using pre-calibrated wireless modules helps avoid the complexity and cost of calibrating an assembled embedded system during its manufacture.
Software integration
One of the first considerations in integrating a Wi-Fi module into an embedded system is the choice of interface between the microcontroller and the module. The choice is made based on several factors:  the available interfaces on the microcontroller itself, the data throughput required in the application, the complexity of the software required to control the interface, and of course, the availability of options in a chosen Wi-Fi module or set of modules being considered.

The ideal scenario for an embedded designer is to first choose a microcontroller best suited for the application, and then make a choice from available interface options. Systems that have traditionally used WLAN, such as routers, laptops, smartphones, commonly have high throughput needs and use interfaces such as PCIe or USB.

In embedded devices, however, the focus is usually on low-power interfaces such as SDIO, Serial Peripheral Interface (SPI), or UART. SDIO offers high data throughput and is used in relatively high-end embedded systems–especially those that transfer large amounts of data such as video or images. High-end microcontrollers provide SDIO interfaces, almost always in conjunction with a resident operating system, while common general purpose 16-bit or 8-bit microcontrollers do not.

In these cases, embedded designers choose between the SPI and the serial UART interface. SPI is a serial interface with synchronous data clocking that can be used to transfer blocks of data in byte-oriented ‘address followed by data’ format. The interface is generally firmware configured which can potentially vary slightly from one microcontroller type to the other.

SPI is a low-power interface and can provide for fairly high application level data throughputs of up to 15 Mbps or more. The UART asynchronous serial interface is a universally available data transfer mechanism in microcontrollers. The interface is limited in its throughput.

While baud rates of several Mbps are possible, a majority of implementations limit this to 115.2 kbps or less. The UART scheme provides for transfer of control or data through special ‘AT commands’ or indicators. In emerging applications, particularly in appliances or devices which are being migrated from a simple wired or proprietary wireless connection to standards-compliant Wi-Fi, the UART interface is perhaps the most easy to integrate.

Adding a standard Wi-Fi interface into an embedded system involves fairly complex software integration. A good proportion of the WLAN protocol stack is implemented in software or firmware, and packet transfer over a standard network requires the presence of a TCP/IP networking stack.

In addition, wireless connection management and authentication also involve specialized software. Figure 2 lists the software segments of the Wi-Fi interface in hierarchical order assuming a traditional partitioning of functionality between the WLAN device, with its own embedded processor running MAC functionality, and the host microcontroller equipped with an operating system.

Click on image to enlarge.

Figure 2.  The software components of a WLAN system

This architecture has a portion of the WLAN stack and the entire networking stack, along with connection management, running on the host processor.

Connecting your wireless “Internet things” simply
The new class of devices that make up the ‘Internet of Things’ may have little in common with other legacy devices that use WLAN such as laptops or PDAs. These devices–remote sensors, industrial control systems, medical diagnostic devices, smart appliances–may use microcontrollers optimal for their application, small or no operating systems, limited memory, have no interactive user interface that can be used for WLAN configuration, and have stringent battery life requirements.

The integration of a Wi-Fi interface into these systems should not only have a minimal impact on the system configuration and resources used, but also on the design methodology itself.

Click on image to enlarge.

Figure 3.   A Cypress PSoC Evaluation Kit, shown with an attached Wi-Fi card

As an example, let us consider an embedded design built using a PSoC processor from Cypress. An easy to use evaluation kit is shown in Figure 3 above, and a screenshot of its development environment also shown in Figure 4 .

The development environment, called the PSoC Creator provides an easy way to integrate various functional requirements of the design. It provides a graphical design editor control hardware configuration and software development in a unified tool.

Click on image to enlarge.

Figure 4.    A screenshot of the PSoC Creator Development Environment

Adding Wi-Fi connectivity to a design based on a PSoC processor is made easy by using a suitable development kit such as, for example a Wi-Fi Expansion Board kit from Redpine Signals.

At the development or prototyping stage of an embedded design project, the Wi-Fi kit can be plugged into the expansion port of a PSoC kit, as in Figure 5 . The Redpine-provided component would be loaded into the PSoC Creator and configured by setting its properties as required in the Wi-Fi network to be used. The inclusion of the Wi-Fi driver in the software configuration is made as simple as a drag-and-drop procedure in the Creator development environment.

Click on image to enlarge.

Figure 5.  The Redpine Wi-Fi Component in the PSoC Creator

The compiled object code is then loaded on to the kit and the kit would then be ready for its intended application with active WLAN connectivity. The fully self-contained nature of the Redpine module ensures that the additional resources required on the microcontroller are minimized.

This approach makes the integration of Wi-Fi connectivity into an embedded design as easy as using any simple wired interface.

Narasimhan Vinkatesh has over 24 years of engineering and management experience in wireless system design, telecommunications, optical networking and avionics. Mr. Venkatesh is a key wireless technologist and champions the universal integration of wireless into embedded systems. His responsibilities include leading the development of wireless systems at Redpine's development center in Hyderabad and their application into diverse industry areas. Mr. Venkatesh holds a masters degree in electrical engineering from the Indian Institute of Technology, Madras, India.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.