original article written in Sept, 2007
How does one implement WiFi functionality in vertical, low volume portable products? This is a good question, and one I’ve been struggling with for the past 3 months. I have a customer who is designing a portable data acquisition system based on a AT91SAM9260 processor, and needs WiFi functionality. The fundamental problem is that no one has time to deal with low volume customers, and the task of implementing WiFi functionality is obviously complex. At volumes of 5000 units a year or less, it makes a lot of sense to go with a WiFi module rather than trying to integrate the WiFi chipset on the board. This article covers some of the options we have looked at and some of the possible solutions.
How is WiFi done on x86 systems?
With desktop Windows, most devices are well supported by device manufacturers. With x86 Linux some of the devices are well supported by OSS drivers, but these tend to be PCI or USB devices. Some of the devices that are not supported can still be used by running the Windows NDIS drivers inside of ndiswrapper, which allows you to run the Windows driver on a x86 Linux system, but this obviously does not work very well on non-x86 processors such as ARM.
WiFi solutions for portable, embedded systems
While there are many off-the-shelf solutions for PCs, Notebooks, etc, the current solutions are generally in the USB formfactor. The ideal solution for portable systems running non-x86 processors are the small modules that connect to the host processor using the SDIO or SPI bus — like the modules you would find in newer cell phones and PDAs. Older modules tend to use the Compact Flash interface, but these modules tend to be larger and are not packaged as nicely for deeply embedded applications. So Ideally we want:
- a modules with a SDIO or SPI interface
- packaging options such as solder down for robust packaging
The scope of this article is limited to modules that implement a SPI or SDIO interface. Why are we interested in modules? Putting a WiFi chip down on a custom PCB is a lot of work. Because the WiFi silicon includes a processor, if things do not work, it may be very difficult to debug. There is also the issue of factory calibration which usually requires proprietary PC based tools that can communicate directly with the WiFi silicon. If the WiFi silicon is buried in your product, getting all this to work can be a challenge. The test equipment required for calibration is expensive. Add to this the difficulty in getting support from anyone who makes WiFi silicon …
It should be noted that WiFi modules are fairly complex devices. They are typically based on a highly integrated IC that includes an ARM processor, Flash memory, and radio circuitry. The fact that these modules include a significant amount of firmware on the module contributes significantly to the complexity of getting WiFi solutions to work properly. Hopefully no bugs are encountered in the module firmware, because I can only imagine how difficult it would be to get these fixed for a small customer. The fact that the module firmware is involved in many of the WiFi functions like authentication further complicates the problem with the abundance of authentication and encryption options available for WiFi. The worst possible problem is the case where you must design an embedded WiFi system that must operate at the enterprise level in every environment. It is one thing to design a system that works most of the time in most environments where WiFi is more of a convenience (like a Cell phone or PDA). It is another thing to design an industrial grade system where it must work all the time and in all environments.
The Fundamental Problems with low volume embedded WiFi
I have never worked with a technology with so many dead ends as embedded WiFi modules. Many of the companies I email or call never even bother to return emails and phone calls. This is certainly true of the chipset manufactures. From what I can gather, the fundamental problems are:
- WiFi implementation is difficult; therefore, a manufacturer’s scarce resources are dedicated to high volume customers. Low volume customers are a significant distraction.
- WiFi companies are very busy right now — they are not hungry for business from small customers.
- WiFi solutions are very competitive and highly proprietary. Many companies are very secretive and will not release driver source code. This is certainly true at the module firmware level.
There are many WiFi module manufacturers and resellers out there, but very few of them offer any type of driver solution for Windows CE or Linux other than binary modules that are supposed to work on perhaps one reference platform. Sorry, this is not going to cut it. So, with plenty of hardware available, the gating item is the availability of software drivers and knowledge of how to use the software. It would seem to me that this is the perfect opportunity for chipset vendors to open source some drivers and develop vibrant support communities so that their modules can be used without a lot of hand-holding by the chipset vendors.
So What are the options?
The Atheros AR6001 seems like a nice solution. The driver situation for the AR6001 is progressing. For Windows CE, there is an opensource WinCE 6.0 driver available at: http://www.codeplex.com/CEWifiDriverAR6000/. Unfortunately, this project appears to be a snapshot of code and does not have any significant amount of community activity or development. Perhaps once more AR6001 modules are available, this will change.
For Linux, there are several options:
- Atheros has released a driver that is available: http://sourceforge.net/project/showfiles.php?group_id=186068. There are several issues with this driver in that it is written for a SDIO stack that will likely never be part of the mainstream kernel.
- A driver is being developed as part of the OpenMoko project.
Embedded Works supplies Atheros based modules and development boards: http://www.embeddedworks.net/wlan/oem_sdio_80211g.html. AR6001 development boards are also available from Cardaccess: http://www.cardaccess-inc.com/products/index.php?a=wlan_sdio.
The Marvell 88W8385 seems to be a very popular IC in WiFi modules available from a number of different companies. OSS Linux drivers are in progress and are reportedly somewhat functional at this point, so it is probably just a matter of time before these devices are well supported in Linux. This chipset/driver is often referred to as “libertas”. The SDIO stack being developed for the Linux mainline (http://lwn.net/Articles/242747/) is where support for this device is being developed.
For Windows CE, it seems the only option is to get the drivers from Marvell, which is a very difficult and time consuming process — at least for low volume customers. First you have to find a module reseller that can get you the source code from Marvell, and then the process takes about 3 months.
There are a number of other WiFi Silicon manufacturers and module vendors, but the driver options from them seem to be very limited in the form of binary only drivers that will only work with certain processors/operating systems. As noted before there is almost no hope of getting anyone to even talk with you if your volumes are low. So your only hope is finding a module vendor that can do any driver work for a NRE fee, obtain the source from the silicon manufacturer, or use OSS drivers.
The Embedded WiFi situation is changing fast, so by the time you read this, it is probably already out of date. We are currently at the phase where it is very difficult to deeply embedded WiFi in low volume products. I expect this will change during the next year. Eventually, WiFi modules re-sellers will figure out that supplying hardware is just one side of the equation. As things get more and more complex, the software availability and support is becoming the gating item.
Many thanks to James Nahra, Dave Anders, and Erik Strack for sharing information and their WiFi experiences with me over the past few months.