Issue
146 September 2002
Build
Your Own 8051 Web Server
by
Jim Brady
CAN
IT BE DONE?
Can
a CPU with only 2 KB of RAM really handle large Ethernet
messages and the complexities of protocols such as TCP
and ARP? Surprisingly, it turns out that even a few
hundred bytes would suffice. Small RAM footprints work
with TCP because you can tell the other end to limit
the message size. TCP can, for example, advertise a
maximum segment size of only 100 bytes.
TCP
checksums are computed over the entire TCP segment and
placed near the beginning of it. This makes it desirable
to hold the entire segment in RAM to compute its sum.
But here again, if the segment is small, this is not
a problem. You can also handle IP processing in a small
memory space, as long as you do not try to reassemble
fragmented incoming messages. And you do not need to,
because the other machine’s TCP layer will limit the
size of the message it sends. Only UDP will send you
large, possibly fragmented messages, and I’m not trying
to support that here. To serve a web page, the only
other protocol you need to worry about is ARP.
A
web server must handle ARP requests because you will
receive them when the other end wants to find out your
hardware address. You also need to originate your own
ARP requests in order to find out the hardware address
of the device you are sending to. Of course, you could
simply reply back to the same hardware address that
sent you the frame, but this would only work for a server
(not a client) on a local network. In addition, this
would get complicated with multiple simultaneous connections.
ARP
is a simple protocol that can cause big problems for
a small server. An ARP request must be sent, and a reply
received, while a regular message is waiting to be transmitted.
One send buffer no longer suffices. You need more space
(i.e., enough RAM to hang on to the message-in-waiting),
and you must buffer the outgoing and incoming ARP messages.
It’s a good thing that ARP messages are only 64 bytes
long. Figure 2 shows how ARP fits into the flow of things,
as well as the flow of an Ethernet frame through the
various protocol layers. The firmware is written so
that the functions in each protocol layer are concerned
only with that layer.
|
(Click
here to enlarge)
|
Figure
2—As a message goes up the left side of the flow
chart, two checksums are verified before reaching
the TCP state machine. Web page requests generate
an HTML page or image, and then two checksums are
added going down the right side. ARP message flow
is shown in the central portion of the chart. |
WHAT
DO YOU NEED?
My
web page includes a JPEG image, which the browser loads
after the HTML portion. Most of the browsers I tested
establish a single connection to load both parts of
the page. Netscape 4.7, however, opens two separate
connections to the server, and the loading of the HTML
page and image overlap to some extent.
Each
connection comes from a different port on the browser’s
machine. To handle this situation, I put all connection-specific
information, such as client IP address, client port
number, sequence number, ack number, and TCP state into
a structure that’s indexed by the connection number.
Each element of this structure can be thought of as
a connection.
When
a TCP segment arrives, I check to see if it matches
an existing connection and use the state information
for that connection. That allows the web server to handle
simultaneous connections from the same PC or from multiple
PCs.
Beyond
ARP, IP, and a TCP state machine to handle simultaneous
connections, what do you need, and what can you safely
leave out? TCP has a long list of goodies, such as algorithms
to estimate the best time-out, avoid congestion, assemble
out-of-order segments, and so on. I made a list of about
20 such items. The truth is that I am serving web pages
to various browsers and multiple PCs simultaneously,
but I’ve implemented only a few of these capabilities.
So, I am content for now, and I have a 20-item to-do
list for a rainy day.
EMBEDDED
WEB PAGES
My
program uses 22 KB out of the 32-KB on-chip flash memory,
leaving enough room for my 7-KB web page. Access to
on-chip flash memory is fast. For more storage, the
obvious choice would be an SPI serial EEPROM. 64-KB
devices are inexpensive, and they can be clocked in
the 2- to 5-MHz range, depending on the part. Using
the built-in SPI port on the C8051F005, set to provide
a 2-MHz SPI clock, my 7-KB web page could be transferred
into the 8051 in about 30 ms. This would add about 50%
to the time needed to serve the page.
Web
pages for embedded systems need capabilities that simple
static web pages do not, such as dynamic data and two-way
capability. Dynamic data is handled by inserting a tag
in HTML. A tag number is included to tell the server
what variable to insert. Two-way communications is provided
using a form, which is a standard HTML construct that
allows the browser to send selections back to the web
server.
One
purpose of a small web server like this is to make a
product easy to use. A little eye candy is nice, and
web pages for embedded systems would do well to have
one or more images to make them attractive.
Photo
2 shows my web page, as presented on an MSIE browser.
This page is bidirectional in that it both displays
data and has radio buttons to turn an LED on the breadboard
on and off. The state of the buttons is sent to the
web server in a post message and can be easily extracted.
The 0.8-KB HTML portion of the page and 6.2-KB JPEG
graphic combine for a total of 7 KB. This page is used
as the basis for comparisons later on in the article.
|
(Click
here to enlarge)
|
Photo
2—Seeing is believing! The web page and image served
by the 8051 can be seen in the browser window. The
on/off buttons control the state of an LED on the
breadboard. |
