Hi, There was a recent project in Circuit Cellar which just about implemented a *limited* version of UDP/IP over a serial link (forget whether SLIP or PPP) on a PIC. This in itself was an impressive feat. Bear in mind that UDP is an order of magnitude simpler than TCP. There's no way that the guy you're referring to has implemented TCP in under 100 instructions. Not any meaningful form of TCP, anyway. However, he states categorically that his stack is fully RFC compliant. Frankly, there are enough suspicious aspects about this guy's claims that I'm pretty much convinced it's bullshit, or there's some massive catch. If it's the former, I'm a bit bemused as to his motives... it's not even funny, as hoaxes go. Cheers, Ben Thomas Brandon wrote: > > http://www-ccs.cs.umass.edu/~shri/iPic.html has links to all the details > (not on this page, spread throughout the site). I was able to discern the > following: > 1) It connects to a DEC machine running Linux acting as a router (he calls > it a router, I call it a PC) via a COM port. It uses the SLIP protocol at > 115200 via bit banging (It's on a 12C509 so no USART). I have never > implemented a bit banging routine but when I was investigating MIDI I read > articles suggesting that doing 2 way MIDI (~32000bps) in a 10MHz PIC would > be difficult so I can't imagine 2way 115200bps via bit banging with TCP/IP > on top can be easy). > 2) No code appears to be published. The closest thing to a description of > the code is: > The PIC has 1024 words (12-bits) of program ROM, > ~256 bytes contain a hand-crafted RFC1122-compliant implementation of > TCP/IP including. > HTTP/1.0 and i2c eeprom Filesystem, using 3 to 99 instructions. > TCP and UDP protocol stack, using 70 to 99 instructions. > ICMP [supports upto ping -s 11], using upto 14 instructions. > IP - Internet Protocol, v4, using 68 to 77 instructions. > SLIP - Serial Line IP packetisation, about 76 inst > Fully buffered UART, upto 115200 bps, using 38 to 56 instructions. > Operating system: RTOS with Rate Monotonic Analysis, using 3 to 15 > instructions. > I fail to see what this is actually saying. True the PIC has 1024 words, > this to me would imply he's giving implementation lengths. Yet he gives > large ranges which can't be implementation lengths (i.e. an implementation > cannot have 3 to 99 inst. it can take 3-99 inst. to run sure but it has to > consist of a certain number of lines of code. Okay, ~50 is valid but 3-99 > isn't). So what is he saying. The PIC may have only 1024 words but this > doesn't mean it can only run 1024 instructions. It can run infinite number > of instructions they just must all fit in the available space. So shouldn't > there be 2 figures, implementation length and running length. Of course > without details such as inputs running time is pretty useless. For instance > the HTTP/Filesystem could takes 3 instructions iff the packet is empty and > take 90-99 inst otherwise so this isn't much use. > 3) I notice there appears to be some link between pages and ports. Notice, > every page is on a different port. At one point he mentiopns the Filesystem > can handle 64 files. I took this to mean he was chcking 64 ports and linking > them to files. However, through testing, it is not simply dependent on the > port. It is at least checking what the filename is. However if you change > the filename but not the port you don't get an error it just time's out > (although this happens regularly anyway so it's a bit hard to tell). My > guess would be the server is partitioned into 64 portions (I will call them > subwebs). Based on the port the filesystem calls the appropriate code > section. This section then checks the filename to process the page. This > would keep the filesystem itself fairly small as it only has to deal with 64 > numerically identifiable sub webs rather than looking at the actual file > name. > > All in all I think it is an impressive project but not neccesarily in the > sense it is intended. I would question it's status as a true web server. > However, I think it is a very good demonstration that even a protocol as > complex as TCPIP can be implemented in a PIC. The key is to analyze the > protocol and cut it down to it's bare bones. It mis technically a wevb > server. You enter a given address, it gives you the page. There is nothing > in the definition of a web server that a file /index.html has to actually be > stored as a file of the same name in the local file system. So I commend the > maker for there excellent analysis skills to pick up on the key points of > TCPIP so as to implement only what is strictly neccesary. However, I > question the stress on it being the world's smallest complete web server > implementation (that's not too say this isn't true). > > BTW: Circuit cellar > (http://www.chipcenter.com/circuitcellar/july99/cmain.htm) has an artticle > on a $25 web server based on an Atmel MCU and a PC ISA network card. It's > pretty impressive and you don't need a router/linux box or even a hub (It > even does BOOTP which makes it more impressive as a full implementation im > my mind). > > Tom. > > NB: I was originally directed to the above two links by PICList posts from > Matt Bennett and Wendy & Guy respectively. Thanks. > ----- Original Message ----- > From: PIC development > Subject: Re: PIC Web Server > > > Yes, > > there's also a reference to it on the latest netsurf (issue 5.25) > > from www.netsurf.com. I looked at the site, but I couldn't find > > any source for the TCP-IP stack they claim. > > Are they publishing the code anywhere? > > > > The text says the PIC runs a serial protocol (SLIP, PPP?) at 115200 Baud. > > > > regards > > Pete