Issue 142 May2002
I-Way the Hard(ware) Way

---

PROTOCOL POWER TRIO

Like the ’7600A, the ’3100 handles IP with TCP and UDP. These are the foundations of the Internet upon which the fancier layers of alphabet soup (SMTP, HTTP, etc.) rest. As a refresher, recall that UDP is a relatively simple no-connection scheme that dispenses with many of the fancier features (flow control, reliable delivery, etc.) found in TCP.

The block diagram seems to imply that the ’3100 also handles protocol trinkets such as DHCP, ICMP, and ARP but I found little reference to them in the documentation. As best I can tell, they might require extra software, likely utilizing the so-called RAW option that bypasses the TCP and UDP layers.

Driving the chip seems straightforward. Registers occupy a 512-byte chunk of the 32-KB address space (see Figure 2). Just like setting up an account with an ISP, there’s a set of registers that define the local IP, MAC and gateway addresses, and sub-net mask.

(Click to enlarge)

Figure 2—Connecting the W3100 to a host is as easy as wiring up an SRAM chip. A full 15-bit address bus provides direct access to the on-chip registers and buffers.

The remaining registers are duplicated four times, one set for each of the four sockets. To create a socket, start by initializing the registers that define the destination IP address, port, and the protocol in use. After a socket is initialized, most of the action switches to individual command, protocol state, and interrupt status registers. When it’s time to move some data, there are transmit and receive pointers that keep track of the SRAM addresses for each socket’s packets.

PING-PONG

Getting this far involves no more than a review of the documentation on i2Chip’s web site. But, I learned long ago not to get too excited about a chip until I can get my hands on the real thing. As you can see in Photo 1, i2Chip has successfully made the transition from paper-ware to hardware.

(Click to enlarge)

Photo 1—The EV kit proves that even a lowly ’51 can get on the Internet with a boost from the W3100.

The 8051-based W3100 eval kit is a real-world version of the prototype three-chip (MCU, W3100, PHY) design shown in the brochures. The MCU is a plain ’51 running at 24 MHz (i.e., 2- MIPS), and the PHY is a RealTek 8201.

There are a few more chips on the board, but I don’t hold that against the W3100. To make life easier, the board design includes external flash memory and SRAM chips. It’s important to note that these extra chips are a matter of easing evaluation and generally wouldn’t be necessary in a production design. Similarly, the board also throws in an RS-232 interface for downloading and debugging.

Bringing the kit to life is as easy as connecting the Ethernet and serial ports to a PC. The presence of an Ethernet link LED on the board helps with the issue of crossover cables. You know you’re all set when the LED lights up.

The manual recommends verifying the installation using the DOS ping command (see Photo 2) before proceeding. Naturally, it didn’t work at first. The manual makes no mention of specific PC network settings, but I figured I’d have to fiddle with them. The key is to turn off DHCP and hardwire your PC’s IP address to let it reach the board (see Photo 3), then ping away.

(Click to enlarge)

Photo 2—The first step after connecting the EV board is to see if the PC can find it using the ping command.

 

(Click to enlarge)

Photo 3—To get started, keep things simple. Hardwire the IP settings on your PC to allow it to reach the W3100.

After the basic connection is proven with ping, the next step is to run a loop-back test program that shovels data from the PC to the board and back again. The EV board’s side of the program is supposedly loaded into the flash memory, but if it is, my PC couldn’t hook up with it. Time for plan B.

The CD that comes with the kit contains copies of all the software (including source). So, I just changed a jumper on the board to switch program execution from the flash-memory chip to the SRAM and used the monitor to download the loopback.hex program. Despite some glitches (the program prompts with an incorrect IP address) and a funky user interface, that did the trick.

I experimented with the loop-back program using different size files. For a huge file, the program reported a symmetric 200 kbps in and out of the chip (see Photo 4). However, switching to smaller files (e.g., 4 KB–32 KB) affected both the symmetry and overall throughput. The latter varied from as little as 20 kbps up to 400 kbps.

(Click to enlarge)

Photo 4—Transferring a 1-MB file, the W3100 delivered nearly 200-kbps throughput full duplex (i.e., it took about 40 s to send the file from the PC to the W3100 and back again.

I tried to explore this phenomenon, but must admit I got bogged down in the source code, especially the PC-side of things. The Microsoft toolchain generates a bunch of bloatware in dozens of files for the simplest task. After I finally found the part of the program that was actually doing something, I had to concede that the code was somewhat over my head, certainly in terms of deciphering actual activity at the chip level.

A bit of ASM would have gone a long way to help see what was actually going on, but only the source and object files were provided and I didn’t have either of the C toolchains (Microsoft for the PC, Keil for the ’51) to go further.

It’s not surprising that the characteristics of the data traffic would affect throughput, but I’m left wondering the exact nature of the relationship, nevermind the proper strategy for optimizing performance.

One clue is that, along with the 200-kbps bulk throughput for the 2-MIPS ’51, i2Chip literature also mentions a 400-kbps rate for a Dallas (now owned by Maxim) ’51-based version of demo board. Because the Dallas chip is three times faster than the standard ’51 (i.e., 4 versus 12 clocks per instruction), it’s an indication that network throughput is heavily, but not completely, dependent on host MCU performance.

That’s rather disappointing because an ostensible benefit for the hardware protocol approach would be to offload the host, and to the degree it does, decouple host and network performance. Without further investigation, my conclusion is that blinding network speed (as you might expect from a hardware solution) isn’t what the W3100 is all about. On the bright side, I envision many of tomorrow’s low-cost, deeply embedded Internet applications as having minimal bandwidth requirements.

Although the ’3100 runs on a 3.3-V supply, the I/O lines are 5-V tolerant, easing interface to existing designs that use the higher voltage. Note that power consumption is a mere 2 mA (typical at 3.3 V), so Internet enabling an embedded gadget doesn’t have to bust the power budget. Contrast that with higher-end alternatives (e.g., embedded PCs) that can easily consume 100 times that amount of power.