Apart from the good link to ethernut which the other poster provided, there are many such projects around. In particular I can recommend you the Book from Jeremy Bentham "TCP/IP lean" which contains a PIC Webserver example and all TCP/IP related information source code etc.
The best piece of information to get me started was the slaa137.pdf / slaa137.zip technote from TI which describes how to implement the very subject on one of their MPU's. I found the TCP/IP stack there (including all source) a very good starting point in that it really focuses on the "bare bones" of the topic. It's therefore easyier to understand. Reading the related RFC's (start with RFC 793) will also help a great deal. Understanding the TCP state engine - while not rocket sience - is not that easy at the first glance. You therefore may have to use multiple sources.
If you want to go the easy route or find it too dificult to implement all by yourself you may also want to take a look at what Rabbit Semiconductor offers (
). There you can get Core Modules all ready including a complete developement envireonement with a TCP/IP stack, Webserver code etc. etc. Another probably similar aproach is the EZ80 stuff from Zillog. They don't work with PIC's though.
If you intend to do more stuff with your developement except for switching two or three things on and off through the webserver, you probably should consider using something other than a PIC. In other words - it's doable with the PIC, but apart from the webserving there are probably not much resources left to do other things.
I don't think you'll be able to implement a robust TCP/IP stack and HTTP server on that microcontroller without external RAM and probably external flash.
Rabbit Semiconductor has complete development kits for Ethernet-enabled core modules starting under $200. A full version of the compiler and TCP/IP stack with source code is included with all dev kits. You won't get to implement your own stack (a very non-trivial task), but you can still learn a lot.
Here is a live web server demo running on a core module:
Thanks guys but I should have added to my original message that I intend to stick with the PIC. I know there are other microcontrollers out there which might be better suited for this task. My objective however is to learn more about TCP/IP and struggle through it.
My idea for this project was fired when I heard a couple years back of a guy who built the smallest webserver by using the smallest 8051 chip he could get his hands on. I figured if he could do it on such a small chip, I should be able to do it on a much larger 40 pin PIC 877.
I'll check out the resources you recommended for learning this. Right now I'm studying the basics of TCP/IP.
That's exactly what I had in mind except I plan not to use an external EEPROM to store webserver files. In fact I remember visiting the guy's iPIC server when he first got it up. It attracted so many visitors that the little iPIC crashed. He had to take it offline and set up a simulated version of it on a webpage. I remember reading the text file 'History of the World' on his iPIC though. :)
Now if only he had provided the TCP/IP code and explained it. He claims the TCP/IP code fits in just 256 bytes with the EEPROM chip holding the server's files. Pretty impressive little gizmo.
You may also want to look at the Wiznet chip. This is a chip that runs a TCP/IP stack which you can access as am 8 bit peripheral or via an I2C Bus. It can handle up to 4 simultaneous links, which should be fine for any sort of web based user interface. With the W3100A you need in the order of 10 instruction lines to be able to ping your device.
It's clever, but it's not what the author claims it to be. Here's the rough algorithm for how it probably works:
receive header of IP frame (via SLIP)
swap destination and source addresses (and ports)
send the modified header in reply
use the destination port number as EEPROM address
send the data found at that address, byte at a time
It gives somewhat the appearance of a real TCP/IP stack, but it certainly *not* RFC-1122 compliant as the author falsely claims. For instance:
The IP layer MUST implement reassembly of IP datagrams.
We designate the largest datagram size that can be reassembled by EMTU_R ("Effective MTU to receive"); this is sometimes called the "reassembly buffer size". EMTU_R MUST be greater than or equal to 576, SHOULD be either configurable or indefinite, and SHOULD be greater than or equal to the MTU of the connected network(s).
Obviously, this implementation (and all similar ones) cannot support reassembly because they simply don't have enough memory to store a full frame (which MUST be greater than or equal to 576 bytes). Such implementations are interesting but they are not real TCP/IP stacks any more than a toothpick is a grand piano.