January 2005, Issue 174

Embedded Wi-Fi with TRENDnet

---

HARDWARE DEFINED

A couple of microcontrollers immediately come to mind that have more than sufficient resources to handle the logic behind my Wi-Fi design. However, not all Circuit Cellar readers have a comprehensive library of microcontroller-specific assemblers and compilers. Nor do all of you page turners use the same brand of microcontroller. Thus, you might not have the tool suite for the microcontroller I selected as the Wi-Fi host controller. So, to solve that problem, my Wi-Fi design allows for the inclusion of any suitable microcontroller capable of driving a PCMCIA or CompactFlash interface to be used as the Wi-Fi host controller.

If you break down my Wi-Fi main board hardware into subsystems, you’ll end up with four universal hardware modules. Here, “universal” means that the subsystem modules are simple, time-proven, by-the-datasheet circuits that you’ve probably built a million times.

The entire design, and hence the universal subsystem hardware, depends on the Wi-Fi radio medium I choose for my embedded Wi-Fi device. There are multiple Wi-Fi radio designs to chose from that can be easily obtained commercially. Because my embedded Wi-Fi device is microcontroller-based, my radio choices were narrowed to a handful of Wi-Fi semiconductor manufacturers. After some exhaustive research, I selected the PRISM architecture because I could positively identify and easily purchase both PCMCIA and CompactFlash Wi-Fi products that contained the PRISM chipset. In fact, a number of web sites contain a list of the various manufacturers’ Wi-Fi cards and the chipset they contain.

As I surfed the ’Net, I noticed that most of the Wi-Fi cards compatible with my Wi-Fi design were also highly recommended for use in a Linux environment. In addition to identifying PRISM-based radio cards, some of the Linux Wi-Fi sites provided a one-sentence translation for PRISM terms in the PRISM driver source code comments and Linux-generated Wi-Fi error messages. I found this refreshing. If you’re walking blindly into the world of Wi-Fi without any access to the confidential PRISM chipset documentation, you’ll find the PRISM lingo in the Linux source code difficult to hash out.

I also joined the PRISM camp because the other Wi-Fi semiconductor manufacturers didn’t respond to my requests for technical data. PRISM was also a good choice because the PRISM idea was born and raised 30 miles south of the Florida room.

After I chose a Wi-Fi chipset, I selected the Wi-Fi radio’s form factor. PCMCIA Wi-Fi form factors are no more difficult to mount on a PCB and interface to a host microcontroller than their CompactFlash counterparts. However, after comparing the PCMCIA and CompactFlash standards documents, I decided that, because of the Wi-Fi CompactFlash PRISM modules’ common 3.3-V operation, the Compact-Flash form factor would be more consistent for end users. It’s also easy to adapt to my universal theme because you don’t have to wonder whether a PCMCIA card is a 5 V-only card, a 3.3 V-only card, or a card that automatically adapts between the two voltages. Another important factor was cost. For the most part, PRISM-based CompactFlash Wi-Fi cards are cheaper than their PCMCIA cousins. As such, the first of the four universal hardware subsystems in my Wi-Fi design, the Wi-Fi radio, is defined.

A number of suitable PRISM-based CompactFlash Wi-Fi cards are available from well-known companies like Netgear, Linksys, and D-Link. However, for the initial design, I chose the TRENDnet TEW-222CF wireless CompactFlash network adapter. If any of the other CompactFlash Wi-Fi cards are better, it really doesn’t matter at this point. My main concern was getting some Wi-Fi hardware fabricated and writing the Wi-Fi driver code with as little extraneous test gear as possible.

I leaned toward the TRENDnet CompactFlash Wi-Fi card because the TEW-222CF, unlike the other CompactFlash wireless LAN cards that provide only a single link LED indicator, is equipped with both a link LED and an activity LED. The addition of the activity LED could provide additional visual status and aid in the production of the Wi-Fi driver code. After the Wi-Fi driver is completed, it should function with any of the PRISM-based CompactFlash cards that I’ve mentioned.

With the Wi-Fi radio hardware module in place, the second universal Wi-Fi main board hardware subsystem’s design points are easily determined. Because the CompactFlash Wi-Fi cards are all 3.3-V devices, the power supply module’s voltage level is fixed at 3.3 V as well. To keep the power supply module universal, I used a National LM1086CS-3.3 voltage regulator surrounded by a pair of 10-µF tantalum input and output filter capacitors. The inclusion of an industry standard 1N5819 in the power supply circuit guards against the connection of a center-negative power brick, while an LED and current-limiting resistor provide visual indication of 3.3 V on the output pin of the LM1086CS-3.3. Any center-positive power brick that can provide between 5 and 9 VDC at 400 mA can be used as the design’s DC power source.

The Wi-Fi design’s power supply and CompactFlash radio configurations also directly affect the third Wi-Fi main board’s universal subsystem’s design point. I’ve included a simple 3.3-V RS-232 interface to aid in the Wi-Fi driver debugging process and to provide a universally accepted external communications path to the host controller.

A textbook circuit employing the Sipex SP3232 brings to bear a standard RS-232 serial port and a pair of modem control signals via a standard female nine-pin shell connector. The Wi-Fi main board serial port is hardwired as DCE, which eliminates the need for questionable crossover cables and clumsy null modem arrangements. The RTS/CTS control signals are optional. I didn’t use them in my implementation, but they’re available if you need them.

The Wi-Fi main board’s fourth major subsystem consists of a host microcontroller or microprocessor, a programming/debugging interface for the host microcontroller, or a microprocessor and an optional host controller power supply if your selected microcontroller or microprocessor doesn’t function to your satisfaction at the 3.3-V level.

The shelves in the Florida room are packed with a bunch of extensive microcontroller tool suites. I baselined a Wi-Fi design based on one of the microcontroller manufacturers that makes a number of proven hardware and software development tools. Again, after the Wi-Fi design concept is validated, it doesn’t matter which microcontroller or microprocessor you choose as your host controller. Your design has to do with how you adapt of the Wi-Fi driver code as well as your ability to construct, debug, and program a custom host microcontroller or microprocessor plug-in hardware module.

The cerebral phase of the project is over when all four of the Wi-Fi design’s subsystems are defined. The next step is to realize the subsystem definitions by designing, fabricating, and populating a PCB based on your Wi-Fi design goals.