| R1 | 100k |
| R2, R3 | 10k |
| C1, C2 | 22pf ceramic disc |
| C3 | 1uF electrolytic |
| X1 | 10MHz crystal |
| D1, D2 | 5 Volt LED |
| U1 | MAX233 - Maxim dual RS232 TX/RX |
| U2 | PIC16F84-10 - 10MHz 16F84 microcontroller |
| U3 | 24C256 - 256kb I2C EEPROM, e.g. ST M24256BN6 |
| J1 | 9 or 25 pin female D connector |
I socketed the microcontroller and EEPROM to allow them to be removed for reprogramming, but you might want to add some provision for in-circuit programming of these parts, especially if using surface mount construction.
The server code implements a minimum subset of the TCP/IP standards, sufficient to provide basic functionality but relying on the SLIP server and client application to fill in the gaps. A stateless TCP/IP model is used; the only information maintained across requests is the server IP packet identification number, which increments each time a packet is served and the initial server TCP sequence number, which is increased by 64000 each time a new connection is requested.
As a packet arrives at the server, the incoming bytes are SLIP decoded and those fields required to reply to the packet are stored. A 20-byte IP header is assumed and any TCP options are ignored - a standard MTU of 576 if used. Non-TCP packets received are silently discarded, while connection attempts to TCP ports other than the defined HTTP port (usually 80) generate a TCP ReSeT reply.
The server's files have 2-digit identifiers in the range 01 - 99. The file system used in the external EEPROM is described in detail below. A default '/' request is served file 01, while requests for non-existent files or invalid filenames receive a correctly headed '404 error' page. Files of multiple MTU length may be served, but the stateless TCP/IP requires that each requested file is served in its entirety before more packets can be answered. Therefore larger files are best avoided if the server is not to appear unresponsive.
The server does not retransmit lost packets and client ACKs are ignored - it is assumed that the client will retransmit its request if a reply is not received. Client FINs are not handled; these are not expected as in normal operation the server closes the connection after the requested file has been served, while if the client aborts the connection (e.g. the browser is closed) an RST is received which does not require acknowledgement.
The PIC server relies on a host SLIP server (typically running Linux or a flavour of BSD) to provide its network connection. The exact commands to set up the SLIP server on the host machine will depend on which OS you use. These work for FreeBSD 3.3:
slattach -h -l -n -s 19200 /dev/cuaa3
ifconfig sl0 192.168.2.2 192.168.2.3 up
(The first IP number defines the address of the server side of the SLIP link). To make the PIC server accessible to other machines on the network, it is also necessary to set up routing and add an ARP entry on the SLIP server.
tcpshow, a freely downloadable BSD / Linux utility which decodes tcpdump output, is a great help when observing the packets travelling across the SLIP connection - in FreeBSD with tcpshow installed, this command gives a live human-readable display of the data being exchanged between the PIC and the SLIP server:
tcpdump -s 1518 -lenx -i sl0 -S | tcpshow -pp -cooked -track
Alteration of the file system contents is most easily achieved by editing a binary copy of the supplied EEPROM image in a decent window-based hex editor such as Hex Workshop. PonyProg will convert between binary and Intel hex formats.
last update - 3/March/2000 (c)2000 Richard Beales