Nuts & Volts - September 2006

E

CD

N

T

E

AE

V

C

D

H

A

N

D

I

S Q

E

U

I

E

H

S

F

T

O

R

G

D

E

S

I

G

N

E

N

C

G

I

Y

N

E

C E

R

L

S

E

■ BY PETER BEST

THE LAND OF TCP/IP

IN A PREVIOUS DESIGN CYCLE (July ‘06), we examined what I consider to be the least complex of all of the Internet protocols — UDP. In that segment of Design Cycle, I also presented some LAN-ready AVR hardware and associated C source code to enable you to use the UDP protocol in your own embedded projects.

In this edition of Design Cycle, we’re going to march cross-country into the land of TCP/IP. Although the same hardware used to transmit and receive UDP datagrams can be used to transport TCP/IP packets, TCP/IP is a bit more complex to code than UDP. However, that’s not going to stop us from getting a microcontroller version of TCP/IP up on a LAN.

Complex things become simple when broken down into component parts, and that’s exactly what we’re going to do with TCP/IP to gain an understanding of how the TCP/IP protocol works. Once you’ve got a grip on TCP/IP basics, I’ll introduce you to some new embedded hardware called the Frame Thrower II that we’ll use to run our minimal TCP/IP stack.

TCP/IP 101

As you can see in Figure 1, encapsulation is used to transport TCP segments within an IP datagram in the same way that encapsulation is employed by UDP datagrams.

If you look at the TCP segment

from an Ethernet point-of-view, the Ethernet type field identifies the frame inside its data area as an IP frame. If the value in the protocol field of the IP header is equal to 6, the packet payload is a TCP segment. To better illustrate this concept, I’ve captured an Ethernet encapsulated IP header of a TCP segment in Screen Shot 1.

TCP/IP was designed to be platform independent. If you’ve ever had the opportunity to loiter in computer rooms, you know that TCP/IP can be run on tiny microcontroller-based systems, personal computers, or large mainframe complexes. TCP/IP consists of a collection of protocols that are standardized in the networking community. The most common way to implement TCP/IP is via a “TCP/IP stack.” Complete TCP/IP stacks can be very large. Usually, a fully compliant stack can’t be easily ported to small, memory-constrained embedded systems like the Frame Thrower II.

Just as we saw with UDP network devices, every machine or device on a TCP/IP-based network — no matter how big or how small — is called a

host. That includes clients, as well as servers. It used to be that a server was always the big machine in the cloud and the client was a workstation on someone’s desk. Today, servers can sit on desktops and servers as well, as clients are becoming more and more microcontroller-based. Regardless of the host’s size, the idea is that all hosts can communicate with each other. This implies that all hosts on all networks can communicate host to host across differing networks. This may sound impractical from a hardware standpoint, but that’s how the Internet really works.

TCP/IP messages are generally short packets of data. Just like UDP, each TCP data packet is addressed to reach a particular host on a particular network. There is no difference in the addressing scheme used for TCP and UDP. The IP address for both protocols is the familiar four bytes divided by dots address scheme (192.168.1.100). Six-byte physical addresses or MAC addresses apply to both UDP and TCP and are used in the identical manner by both protocols.

You’re probably used to hearing the term “TCP/IP” and thinking about

■ FIGURE 1. Encapsulation is what this is all about. The IP and TCP headers are very important parts of the game as they hold valuable addressing information, as well as information about the data contained within the packet.