September 1998, Issue 98

TCP/IP Networking

---

PUTTING IT TOGETHER

Let’s look at the nuts and bolts of implementing a network-based logic-engine device. As I mentioned, I need to build an Ethernet device. In this case, it is an interface to the logic engine, a prototype developed by the Computer Science Department at Indiana University.

Photo 1—This is the logic engine. It’s a large wire-wrap area with a bunch (128 bits) of I/O registers that can be controlled via a PC parallel port. It’s essentially a chip and system tester.

The logic engine (see Photo 1) is used in an undergraduate digital design lab and for research projects. In both cases, it serves as a sort of chip/system tester. Figure 4 gives an overview of the system we plan to build.

Figure 4—This is the system diagram of my Ethernet device. By putting devices on the Ethernet, I make devices more portable and accessible.

The logic engine is an array of 8-bit I/O registers which are read and written by a host via a parallel port interface. Figure 5 illustrates the logic engine’s basic design.

The protocol controlling the logic engine is simple. An 8-bit address is latched by first writing it to the data port of the PC parallel port interface and then strobing the address strobe, which is one of the control signals on the parallel interface. Once the address has been latched, the host reads and writes the register.

Writing it is simple—the host sets the data in the data port of the parallel interface and strobes the write strobe. Reading is a little harder. The content is read by selecting the nibble (upper/lower) of the I/O register and reading the status port of the parallel port. It takes two transactions to read the port in the interface.

Now you have an idea of how the logic engine interface works, so let’s go to work. As a minimum, you need a CPU board with a PC parallel port interface. You also need an Ethernet interface and enough memory to hold the system software.

For the prototype, I chose Versalogic’s VSBC-1 motherboard and their PCM-3660 NE2000-compatible Ethernet module. While it’s overkill for this application, I had one on hand. Using a PC-compatible single-board system with integrated Ethernet, such as Versalogic’s PCM-4890, would be more economical.

Next, I selected an RTOS. My biggest concern was that it has a TCP/IP protocol stack and supports the Ethernet card.

I chose an NE2000-compatible Ethernet card, which is the most common. Nearly all TCP/IP implementations have a driver for it. Eventually I want to ROM this application, so a ROMable RTOS would be good.

For the prototype, I chose QNX, mostly because I can develop the code on the system while prototyping by booting the OS from the network or hard disk. Once it’s done and I don’t need the development system components, I can just ROM the essential modules needed from the OS.

Another OS to consider is RT-Linux, which is a freely available Unix-like Linux OS with a real-time extension. This also lets me develop software online and then embed it.

Although RT-Linux is not as easy to ROM as QNX, it is possible. I can also boot RT-Linux over the network.

I also need to talk about the application-layer protocol I implemented for this project. Recall that the application-layer protocol uses the socket API to communicate with the remote system—here, the logic engine interface. The protocol for the logic engine is simple.

The command is of the form:

<cmd><port><wdata>

where <cmd> can be r for read, w for write, or q for quit. <port> and <wdata> are two-digit hex numbers. Even though only the w command needs data, always send a data byte along. For the r and q commands, the data has no meaning. It just makes each command the same length, which makes buffer management easier.

For every command received, the logic-engine interface sends back a byte again in a two-digit hexadecimal encoding. If the command is a read, it’s the value of the register addressed. So, the response is:

<rdata>

Listing 1 shows all of the application-specific code for this project. The program starts off by setting up a server port. When a connection from a client comes in, you spawn a process to handle the connection and it sits in a loop waiting for commands.

For each r and w command, you perform the transaction on the parallel port and return a byte. If the connection is broken or q is received, the process terminates.

What about the client side? Here, I use a task control language (TCL) program to test the interface. You can find free TCL implementations for Windows, Unix, and Macintosh.

Listing 2 offers a simple test program. It connects to the server and tests some of the logic engine ports. That’s all there is to it.

Well, almost. It’s OK for a prototype, but there are some things that need to be addressed. As I have mentioned, the prototype is overkill for this application.

You only need a low-end ’386-based CPU. Also, I haven’t ROMed the application. Some of that depends on the RTOS we use as well as the particular CPU module.

I also haven’t addressed how an Ethernet-based device finds out its Internet address. My development system boots from disk, so it’s easy to configure the Internet host address in one of the start-up scripts via the console I use for development. In an embedded Ethernet device, however, there probably isn’t a console.

But don’t despair. There are solutions.

One option: include a serial port on the Ethernet device, which would run a small command-line-based interface that lets you configure things like the Internet host address and store data in a flash file system. But, this solution mars the beauty of having an Ethernet device—it would have a console and seem more like a computer.

A better solution is to use one of the protocols available for this purpose. There’s the dynamic host configuration protocol (DHCP) and the boot protocol (BOOTP). The idea: you can use a Windows or Unix machine as an Internet host address clearinghouse.

When turned on, the Ethernet device sends a DHCP or BOOTP broadcast over the Ethernet. A workstation configured to be a DHCP or BOOTP server then assigns an Internet address to the Ethernet device and sends a response. The Ethernet device uses this address until it’s turned off.