Each embedded system in the billions of electronic devices and systems that are all around us addresses a specific dedicated purpose in a very wide range of applications – for example medical diagnostics, geological analysis, electronic surveillance, cash registers the list is almost endless.
They all use microcontrollers to implement a portion of their functionality, and most of them communicate with the outside world – to other devices or control systems, or to a human interface. Connectivity through wireless means provides a great deal of flexibility to the embedded systems, and indeed, in many cases wireless is the only means possible.
In this article, we examine how wireless connectivity based on the IEEE 802.11n standard can be integrated into embedded systems, providing a universal IP based networking that is future-proof, and enabling the 'Internet of Things.'
Throughout this article, we use the term WLAN for referring to the wireless protocol defined by the IEEE 802.11 standard. This term is interchangeably used with 'Wi-Fi' in popular use.
General Characteristics of Embedded Systems
A generic architecture of an embedded system is illustrated in Figure 1 below . The core control functionality is implemented in the microcontroller, and specialized hardware interfaces and peripherals provide the special functionality needed in the particular system.
For example, specific components in the system may include a temperature sensor, an actuator, a keypad, an LCD display, or a camera. Since these systems are largely application specific, they tend to utilize the minimum set of components required for the application.
Memory is therefore limited, and the microcontroller's characteristics – clock speed, number of bits and interfaces – are usually just sufficient to run the applications functionality. The introduction of a new connectivity mechanism would thus be feasible, in most cases, only if it entails little additional overhead.
|Figure 1: A Generic Embedded System's Components|
Connectivity comes in several forms. For example, a hardwired link with proprietary data formats, a standard point-to-point serial link carrying proprietary data, or an IP based network connection transporting data across an enterprise network or the internet.
It is easy to see that standard IP based transport provides the greatest flexibility in embedded systems. The price to be paid is complexity in implementation.
Further, many embedded devices are battery powered – usually due to the circumstances of their deployment and the nature of the applications they serve. These devices naturally veer towards the use of a wireless link through which constant connectivity can be maintained.
The best choice in this scenario would be the most energy efficient wireless mechanism that also directly provides IP based transport. Figure 2 below illustrates an embedded system with a point-to-point serial link, showing the format of data transfer.
|Figure 2: An Embedded Device Communicating via a Proprietary Serial Link|
The serial link physically connects the embedded device to its controller, with the obvious limitations of having the two being in proximity and not having the flexibility of substituting the control function on any other piece of equipment. These limitations are done away with IP based wireless transport.
There are several wireless options available. Our focus is on IEEE 802.11n Wireless LAN, but first we briefly look at Bluetooth and Zigbee. Bluetooth is a wireless protocol for exchanging data over short distances and popularly used in audio headsets. Zigbee is a low-power wireless communication specification primarily aimed at sensor networks.
Both these protocols, however, suffer from two disadvantages. First, they offer low on-air data rates and therefore spend more time on air to transfer data compared to other protocols such as WLAN. Overall, they thus spend more energy in transferring a given amount of information.
Second, they require a complex networking stack – especially so when an IP based transport interface is required. Figure 3 below shows a scenario where the embedded device is equipped with a WLAN interface and can thus to its controller located anywhere on the IP based network.
|Figure 3: Embedded System with WLAN Interface Connected to a Local Area Network|
As shown in Figure 3 the embedded system. The microcontroller's serial or UART interface is used here to connect to the WLAN module. The other common choice of interface here is the Serial Programming Interface, or SPI. SPI provides a synchronous serial link with much higher data rates possible than UART. Depending on the microcontroller used, the SPI clock speed can stretch up to 50 MHz or even beyond.
The IEEE 802.11n Advantage
Most current embedded devices that integrate 802.11 WLAN use the legacy 802.11b or 802.11g standards. The data rates offered by these methods have been deemed to be sufficient for the relatively small amounts of data exchanged by these devices, and indeed, from point of view of the embedded devices, the 802.11b/g data rates easily meet their transport requirements.
But enterprises are increasingly moving towards the deployment of 802.11n based wireless networks. The IEEE 802.11n standard has defined the physical layer and MAC layer characteristics to significantly increase the end-user throughput that can be achieved in a given frequency channel. It has also defined the means to achieve high throughput over a much wider operational range than legacy WLAN.
Because of this 'high throughput' thrust, the 802.11n standard is popularly associated with high speed communications between high performance computing platforms. Less known, but equally significant, is that it enables a much more efficient use of available spectrum.
However, the benefits of 802.11n are realized fully only when all nodes on the wireless network are capable of communicating using 802.11n methods or are compatible with 11n.
The presence of legacy 802.11a/b/g nodes in a network forces the other 802.11n nodes to resort to the use of protection mechanisms to preserve network integrity, thereby reducing overall network capacity by 30 percent or more.
Interfacing a WLAN subsystem to a microcontroller based device requires the consideration of several factors including the physical and electrical specifications, choice of interface, host load, the software architecture, power-save mechanisms, wireless performance, and certification.
The main components of a WLAN subsystem are the Medium Access Controller (MAC), the Baseband Processor (BBP), the analog front-end, the RF transceiver, power amplifier and other RF front-end components as shown in Figure 4 below .
|Figure 4: The Components of a Self-contained WLAN Subsystem|
The subsystem requires a stable frequency reference that is usually provided from a crystal oscillator. In some systems, a frequency reference source can be shared between several functional subsystems.
RF transmission is through an antenna that may either be mounted on the board itself or may be located externally. The integration effort can be minimized by choosing a WLAN module that is fully self-contained. This approach offers several benefits.
The WLAN module is already verified for wireless performance and calibrated. Since all critical RF circuitry is present in the module, and often enclosed in a shield, no performance degradation is expected during integration into the embedded system.
Board layout and assembly are therefore simplified. Even in cases where an external antenna is used, the connection to it would be of low complexity ” typically using a miniature coaxial connector and RF cable. The self-contained module can also be certified independently of the end product.
FCC and certification authorities permit 'modular certification' where a wireless module may be certified and then used directly in a system without the need for further certification. A module with architecture like the one shown in Figure 4 would comply with all the necessary guidelines for this. Figure 5 below is a photograph illustrating such a module.
|Figure 5: Image of a Self-contained WLAN Module.|
The ideal specification for power supply is a single voltage input, with all the other voltages being generated by a power management Unit (PMU) within the module. The PMU also serves to control individual power supply to various blocks within the subsystem for use in power-save modes.
There are several possibilities in the choice of interface to the microcontroller. Interfaces such as USB, PCI or PCIe are used in systems where high data throughput is required ” for example, storage devices, wireless routers, and laptops.
In our current focus on embedded devices, however, the choice is generally made from one of several low-power interfaces including SDIO, SPI, and UART. The Secure Digital I/O (SDIO) interface defines one or four-bit data transport across a synchronous bus with standardized protocol.
With possible clock rates of up to 50 MHz, 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 the latter cases, WLAN integrators choose between the Serial Peripheral Interface (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.
Microcontroller applications with the SPI interface do not necessarily use an operating system as part of their software environment. The synchronous nature of the SPI interface provides for a unique power-save mechanism ” during periods of little wireless activity, most blocks of the WLAN module may be in a low-power sleep state with clocks turned off, while the host interface may still be active and using the SPI clock to receive data from the host.
Some WLAN modules maximize energy efficiency by using this among other power-save practices.
The UART asynchronous serial interface is the most commonly available data transfer mechanism in microcontrollers. Indeed, no microcontroller is known to be without a UART interface. Embedded devices therefore commonly integrate WLAN modules via the serial UART interface.
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.
Software architecture is an important aspect of the integration of Wireless LAN into an embedded system. The WLAN protocol has its own data and connection management requirements, while additional software burden comes in the form of the TCP/IP networking stack and network configuration. Figure 6 below shows the typical complete software stack related to data transfer over 802.11 WLAN.
|Figure 6: Software Components of 802.11 Wireless Data Transport|
It may be seen that the architecture in Figure 6 includes a good deal of the software functionality carried out in the host processor. The problem of upgrading an embedded device from simple wired connectivity to one with WLAN and an IP based network stack is particularly acute due to the extent of software integration required.
This is why it is often the best choice to use a WLAN module that completely implements all the software needed. Figure 7 below shows the delineation of software functionality between the host microcontroller and the WLAN module in such cases.
|Figure 7: Software Architecture of an Embedded Device with all Networking and WLAN Functionality Resident in the WLAN Module|
WLAN Functionality Resident in the WLAN Module
Operational provisions on the embedded device related to wireless connectivity can be further minimized through the provision of a wireless configuration update mechanism in the WLAN subsystem.
During deployment of the devices, wireless connectivity would be established to a default wireless infrastructure configuration. After the connection is established, configuration update firmware functionality can be invoked to modify the connection parameters.
Connection can then be re-established to the newly designated wireless network. In summary, the software functionality of the WLAN module should ideally include:
* Compliance to 802.11b/g and single stream 802.11n
* All the protocol and configurations functions for WLAN connectivity in Open and WPA/WPA2 secure modes of operation
* Serial UART or SPI host interfaces
* Termination of TCP and UDP connections, and offering transparent serial modem functionality
* Configuration updates through UART or Wireless means
* Ad-hoc and infrastructure modes for maximum deployment flexibility
* Implementation of fine-grained power-save methods
* Roaming mechanisms for seamless connectivity across an enterprise
* Transmit rate adaptation for extended range of operation
There are some cases, however, where the embedded system is already built with a TCP/IP networking stack. In these cases, the WLAN module must offer the capability of by-passing its networking stack and thus handle only WLAN transport.
The Development Path – Use of Evaluation Kits
An embedded device, however simple its purpose may be, is really a grand agglomeration of diverse hardware and software components. Rarely do designers – battling with an array of tasks including board design, selection of components, configuration of subsystems, defining performance expectations, creating validation environments, among many others ” get everything right at first attempt.
They route they most often follow is through the use of versatile and flexible evaluation or development kits helpfully supplied by leading microcontroller vendors. These kits provide the ideal development platform where design, performance, and integration issues are resolved. WLAN integration should also, naturally, fall into this path.
Design engineers can, today, use evaluation boards from WLAN vendors that integrate the target wireless module and provide a ready interface for directly plugging into their chosen microcontroller development kit. These evaluation boards are accompanied by software already ported, or easily portable, on to the chosen microcontroller platform.
The typical contents of a complete development kit would also include a pre-configured wireless Access Point. Quickly, therefore, the WLAN interface can be included into the development environment and would be available right through the development, validation, and optimization of the embedded device.
In summary, the Internet of Things will add billions of devices into its fold in the coming years. Wireless LAN based on the IEEE 802.11n standard will be a primary means of connectivity in these devices, and for system designers today, making the right choice of microcontroller platform and Wi-Fi module is paramount to securing successful deployment in this promising market.
N. Venkatesh is the vice president of advanced technologies at Redpine Signals , and has over 24 years of engineering and management experience in wireless system design, chip design, telecommunications, optical networking and avionics. He holds a Masters Degree in Electrical Engineering from the Indian Institute of Technology, Madras, India.