January 2005, Issue 174

Embedded Wi-Fi with TRENDnet

DRIVE THE TEW-222CF

To learn more about what’s required to drive a CompactFlash Wi-Fi card, study the CompactFlash card connections shown in Figure 1. The baseline microcontroller I selected for the initial Wi-Fi design is an 8-bit device. Note that the CompactFlash card connector is pinned for 16 data lines. The CompactFlash card documentation outlines a process to read and write using a 16-bit data path. Assume that the Wi-Fi CompactFlash card can operate in 16- or 8-bit mode, which opens up 16-bit microcontrollers and microprocessors as possible host controllers.

The control and state of the CE1 and CE2 lines depend on how you want to transfer data to and from the CompactFlash card. I chose to control both of the CEx lines logically because I had the available I/O to do so. This led to a self-induced bug that took me a day to smash. I was accidentally logically ANDing the CE2 line low before data transfer. When both CE1 and CE2 are low, the CompactFlash card is put into 16-bit Read/Write mode. For 8-bit mode you can save a couple of I/O pins and simply tie CE1 low and CE2 high. When selecting your host controller, plan for 11 bits of addressing because it will be required to access the internals of the CompactFlash card memory structure.

Using the CompactFlash card I/O control lines is no different than any other I/O control configuration. Combinations of logic levels on the REG, OE, and WE lines read and write standard CompactFlash internal registers while logic levels encompassing the IORD, IOWR, OE, and REG control lines do things to the PRISM-related parts on the CompactFlash card. These I/O operations are standard for all CompactFlash cards and all the combinations of 8- and 16-bit transfers, including the timings in the CompactFlash specification.

The HI-TECH ANSI C is the baseline C compiler for the Wi-Fi main board. I chose it because of HI-TECH’s broad range of supported platforms. Because the Wi-Fi main board isn’t geared toward any particular microcontroller or microprocessor, HI-TECH’s line of C compilers will probably support the microcontroller or microprocessor you select for your Wi-Fi design. For instance, HI-TECH offers ANSI C compilers for ARM, 8051, MSP430, z80, H8, PIC, and 68HC11. Using HI-TECH ANSI C to write the baseline driver and application code, you can port and use the manufacturer’s proprietary ANSI C compiler for your selected host controller. You can also use it to port a processor-specific variant of HI-TECH ANSI C to code your Wi-Fi application.

Becauase the PRISM chipset’s internal operation is confidential, the most logical method of giving public access to PRISM operations is through an API. Listing 1 is all it takes to turn on the radio and associate/authenticate with an access point (AP). wifi_api() is an interface function that you may download from the Circuit Cellar ftp site. Suggestions as to how to implement the API functions are included with the download package.

The matter of business involves starting up the interrupt-driven USART hardware. This call (init_USART) also enables the printf functionality built into the ANSI C compiler. After the USART is operational, you can receive error and info messages from the API via the Wi-Fi main board’s serial port.

All CompactFlash cards must be initialized via the manipulation and reading of the card information structure (CIS) tuple array. This is accomplished using the wifi_api(INITIALIZE,CF) API call. Information needed for communicating with the CompactFlash card internals is gathered during this CompactFlash initialization process. Again, this isn’t a PRISM-only confidential operation. Tuples and the CIS mechanism are discussed in detail in the CompactFlash specification. The only secrets here are what the PRISM tuples contain and how to decode the information within them. A simple tuple dump program exists in the Linux community, and such a program can be easily written and executed in this embedded environment. I did just that, but there’s no use in blurting out a bunch of confidential hexadecimal characters that I can’t legally translate for you.

I persuaded the Wi-Fi board to contact the AP in the Florida room by specifying the network type that I wanted the TEW-222CF to join, which is BSS or an infrastructure network. The Wi-Fi NIC was notified of my choice of networks with the source line wifi_api(NETWORK,BSS). I happened to know that the SSID of the Florida room wireless network is “EDTP,” so I instructed the Wi-Fi board to search for and connect to an AP beaconing the EDTP SSID using wifi_api(CONNECT,EDTP). The following happened: First, the Wi-Fi radio powered up and engaged. Second, the Wi-Fi card transmitted the probe request. Next, the AP acknowledged the probe request. Following this, the Wi-Fi card requested authentication, the AP authenticated the Wi-Fi card, and the Wi-Fi card requested association. After the AP granted the association request, the Wi-Fi board was on the EDTP wireless network.

I kicked off the code and the TEW-222CF’s link light illuminated. A short time later, the Wi-Fi card’s link light started blinking. This indicated that the card was initialized. At that point I started my Netasyst wireless sniffer application on my laptop. After the initial probe requests were sent, I noticed a flickering of the Wi-Fi card’s activity LED and the link light went solid. This indicated that the Wi-Fi board had successfully completed all the necessary steps. I stopped the sniffer and verified the results using the sniffer capture shown in Photo 3.