Design Article
Designing Wi-Fi connectivity into your embedded "Internet thing"
Narasimhan Venkatesh, Redpine Signals
7/11/2011 1:23 PM EDT
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.
Next: Page 2
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.
Next: Page 2
Navigate to related information



Luis Sanchez
7/11/2011 5:12 PM EDT
Nice article. Now I know why is decided to use SDIO as the communication bus between the host microcontroller and the Wireless LAN module when using "big chips" that host an operating system.
And when using smaller chips, UART or SPI is prefered. Its all a matter of performance requirements and desired throughput. Feels good to learn!
Sign in to Reply
mretzer
8/29/2011 11:42 AM EDT
One difficulty seems to be that there is very little standardization of the Hardware Abstraction Layer. The software on the host microcontroller must be very customized for the specific WLAN device. [Unlike the Bluetooth HCL] the choice of host SW, host processor, and WLAN module are very locked together,as is the development environment. There are advantages in this in getting a new project up and running quickly, but there is also a downside when it comes to migration. Any thoughts about a more universal HAL?
Sign in to Reply