Wi-Fi networking is becoming more popular for embedded applications for much the same reasons as Ethernet networking became popular. The technology is familiar; the equipment to set up the network is inexpensive; and it enables easy communication with PCs and other devices on existing network infrastructure. However, implementing Wi-Fi networking for embedded systems poses some special challenges for the embedded systems designer. Which features should you look for? Which are most important? What special considerations should you be aware of? This article aims to help you understand the peculiarities of Wi-Fi for embedded systems so that you can choose the best Wi-Fi implementation based on your needs.

To determine if a particular embedded Wi-Fi solution is right for you, a number of questions need to be posed and answered. This article covers these questions:

• Does the solution provide full Wi-Fi access (including access to socket-level programming) or simply serial-to-Wi-Fi?

• Will the Wi-Fi solution be available long-term? What issues can you expect over the long-term?

• Is 802.11g or 802.11n supported, or only 802.11b?

• Which security (encryption and authentication) features are supported?

• Is the solution FCC-certified? Can you integrate the solution into your product without additional certification?

• What about certification with other regional authorities? Is multidomain (802.11d) supported?

• What is the maximum data throughput for the solution? How does Wi-Fi encryption and authentication affect your throughput?

• What is the power usage of your Wi-Fi solution? Are low-power modes supported?

• Does it provide typical Wi-Fi range, or is performance compromised?

• What is the operating temperature specification?

• How is antenna placement handled, and can you use an antenna other than that which is provided?

• Is roaming from one access point to another handled cleanly?

Each of these questions will be explored in turn. By studying these questions and researching the answers based on your requirements and the Wi-Fi solutions you're exploring, you should be much closer to selecting the right solution for your product.

Serial-to-Wi-Fi or full access?
Many Wi-Fi devices for embedded systems provide only serial-to-Wi-Fi functionality. The idea is that the Wi-Fi device has preloaded firmware, and you use a serial port on your embedded device to interface with the Wi-Fi device. This is very similar to serial-to-Ethernet devices. Serial-to-Wi-Fi devices make it easy to add some limited Wi-Fi capability to existing embedded devices (as long as a serial port is available). This option works well for applications that need only one connection (or socket) at a time. It is especially well-suited for allowing a serial port to be accessed over the network. If you need the ability to run multiple servers or clients on your device (such as a web server, FTP server, and email client), serial-to-Wi-Fi devices probably will not provide enough flexibility.

An increasing number of single-board computers and core modules are available that have Wi-Fi integrated as a native network interface. The native network interface typically allows full socket-level access so that you can run concurrent servers and clients--in other words, a full networking system. This can make for an overall cheaper solution since a separate device is not needed. Of course, if you are adding Wi-Fi capabilities to an existing system, the serial-to-Wi-Fi devices will be much easier to implement as long as the limitations are acceptable.

To access the rest of this article, click here. Currently the article is only available via the free digital edition of Embedded Systems Design magazine but will be posted in full online at the end of the month.

Note: If you haven't registered for the free digital edition, we've improved the interface for doing so: click the link above, fill out a short form, and view the digital edition (where you can download a PDF if you wish). You only have to sign up once for unlimited access to the digital edition. Questions or comments? Send them to Susan Rambo at srambo@techinsights.com.