Post by thread:From slashdot- TCPIP on a PIC

Well... I'm a bit skeptical. Mind you, I've not implemented a tcp/ip stack anywahere, nevemind on a pic, but he has code that: Handles 115200 serial reception and transmission Handles and serves data from an eeprom With a fully tcp/ip stack and http 1.0 server between the two On a chip running at 4MHz. To my knowledge, none of the 12cxxx chips have usart, so he must be bit banging. Probably no error correction. He could be doing a funny interrupt on change and timer combination for reception... I suppose it is possible, but I only say that because I don't know as much as I'd like to know about the tcp/ip stack, which is the kicker, here... -Adam Matt Bennett wrote: {Quote hidden}> > I don't think anyone has mentioned this in the past few seconds... > > This was just posted on slashdot: > > http://slashdot.org/articles/99/07/14/1937221.shtml > > "Jason Asbahr writes " From the wearables list, Shrikumar wrote: > I'd like to announce what is a really tiny implementation of > TCP/IP stack and a really really tiny web-server. " > > Which contains a pointer to: > > http://www-ccs.cs.umass.edu/~shri/iPic.html > > Matt Bennett

>http://www-ccs.cs.umass.edu/~shri/iPic.html The links off this page are down - it appears the PIC is off-line! Andy ================================================================== Andy Kunz Life is what we do to prepare for Eternity ------------------------------------------------------------------ spam_OUTandyTakeThisOuTrc-hydros.com http://www.rc-hydros.com - Race Boats .....andyKILLspam@spam@montanadesign.com http://www.montanadesign.com - Electronics ==================================================================

I was a bit skeptical myself. When I went to his site, I could access "the live iPIC server" So I got to thinking, maybe he didn't implement the WHOLE TCP/IP stack? And maybe he didn't have it set up to work on more than one socket. Seems a little fishy if ya ask me. My 2.49 cents, Tim Hamel In a message dated 7/14/99 1:56:29 PM Pacific Daylight Time, adavisKILLspamBALADYNE.COM writes: > Well... I'm a bit skeptical. Mind you, I've not implemented a tcp/ip stack > anywahere, nevemind on a pic, but he has code that: > > Handles 115200 serial reception and transmission > Handles and serves data from an eeprom > With a fully tcp/ip stack and http 1.0 server between the two > On a chip running at 4MHz. > > To my knowledge, none of the 12cxxx chips have usart, so he must be bit > banging. Probably no error correction. He could be doing a funny interrupt > on > change and timer combination for reception... > > I suppose it is possible, but I only say that because I don't know as much > as > I'd like to know about the tcp/ip stack, which is the kicker, here... > > -Adam >

This is referred to as being 'slash dotted' Slashdot.org serves a few million pages a day, and when an article comes up on it, the web site referred to usually gets a few thousand hits in the next hour, continuing throughout the day until it's off slashdot. They brought down x10.com's servers when they put up a message about the free firecracker kit. This, naturally, will be much more than the PIC can handle, but if you go to slashdot, you'll be able to see what others have posted about it. -Adam Andy Kunz wrote: {Quote hidden}> > >http://www-ccs.cs.umass.edu/~shri/iPic.html > > The links off this page are down - it appears the PIC is off-line! > > Andy > > ================================================================== > Andy Kunz Life is what we do to prepare for Eternity > ------------------------------------------------------------------ > .....andyKILLspam.....rc-hydros.com http://www.rc-hydros.com - Race Boats > EraseMEandyspam_OUTTakeThisOuTmontanadesign.com http://www.montanadesign.com - Electronics > ==================================================================

On Wed, 14 Jul 1999, Andy Kunz wrote: > >http://www-ccs.cs.umass.edu/~shri/iPic.html > > The links off this page are down - it appears the PIC is off-line! from Slashdot: {Quote hidden}> I'll be dipped... (Score:4, Informative) > by Wee (wrhodes1[at]san.rr.com) on Wednesday July 14, @04:01PM EDT (#21) > (User Info) > I got in before the poor guy met an unseemly /. fate: > > [wrhodes@lazlo wrhodes]$ telnet eternity.cs.umass.edu 9080 > Trying 128.119.41.46... > Connected to eternity.cs.umass.edu. > Escape character is '^]'. > HTTP/1.0 302 Moved Temporarily > Date: Wed Jul 14 15:50:36 EDT 1999 > Server: iPic Redirect+Log Hack/1.0 > MIME-Version: 1.0 > Content-Length: 0 > Location: http://sprung.cs.umass.edu:4176 > Connection closed by foreign host. > > There you have it: The smallest server redirect in the world. > > -B :) The general concensus was "it's a bunch of hooey! If it isnt, show me the code." There was also one reference to this month's Circuit Cellar magazine, which looks like it a has a bunch of good articles, including this one (http://www.circuitcellar.com/): > Internet Appliance Interface-Myron Loewen > Internet appliances still aren't the most > reasonable things out there. (Why pay hundreds > more for a $20 toaster?) But, Myron uses a PIC > and a 2400-bps modem to make an Internet > interface that leads the way to less-expensive > Internet appliances. pg. 24 I'm going to get me copy in a few minutes, any other DC PICLISTer's wait till tomorrow, Reiter's only had two copies. - j

I knew it!! If this chip were really a server, wouldn't it have it's own IP addy? instead of it being eternity.cs.umass.edu PORT 9080. And for the FTP server he supposedly stuck on the chip -- that alone would require a few KB's. This is such a tragedy, I actually thought someone did it =( Tim Hamel In a message dated 7/14/99 2:17:50 PM Pacific Daylight Time, johnmspam_OUTMAGNET.COM writes: {Quote hidden}> > [wrhodes@lazlo wrhodes]$ telnet eternity.cs.umass.edu 9080 > > Trying 128.119.41.46... > > Connected to eternity.cs.umass.edu. > > Escape character is '^]'. > > HTTP/1.0 302 Moved Temporarily > > Date: Wed Jul 14 15:50:36 EDT 1999 > > Server: iPic Redirect+Log Hack/1.0 > > MIME-Version: 1.0 > > Content-Length: 0 > > Location: http://sprung.cs.umass.edu:4176 > > Connection closed by foreign host. > > > > There you have it: The smallest server redirect in the world. > > > > -B

Well, as for the port, that's entirely possible, he indicated it was doing SLIP, so it must be hooked up to a serial port of a unix box acting as a router for it. Only tcpip packets meant for the pic will get to it. He did NOT implement ftp, he just named a 'directory' as /ipic/ftpsite He did say that he made a telnet on it, though, so i'm not so sure. If it is a fake, he went to an awful lot of trouble to make sure that when the heavy loads came it didn't serve. His webpage comes right up, but the PIC doesn't when more than a few people query it... -Adam Tim Hamel wrote: {Quote hidden}> > I knew it!! If this chip were really a server, wouldn't it have it's own IP > addy? instead of it being eternity.cs.umass.edu PORT 9080. And for the FTP > server he supposedly stuck on the chip -- that alone would require a few KB's. > > This is such a tragedy, I actually thought someone did it =( > > Tim Hamel > > In a message dated 7/14/99 2:17:50 PM Pacific Daylight Time, @spam@johnmKILLspamMAGNET.COM > writes: > > > > [wrhodes@lazlo wrhodes]$ telnet eternity.cs.umass.edu 9080 > > > Trying 128.119.41.46... > > > Connected to eternity.cs.umass.edu. > > > Escape character is '^]'. > > > HTTP/1.0 302 Moved Temporarily > > > Date: Wed Jul 14 15:50:36 EDT 1999 > > > Server: iPic Redirect+Log Hack/1.0 > > > MIME-Version: 1.0 > > > Content-Length: 0 > > > Location: http://sprung.cs.umass.edu:4176 > > > Connection closed by foreign host. > > > > > > There you have it: The smallest server redirect in the world. > > > > > > -B

Tim Hamel <KILLspamIMDNICE12KILLspamAOL.COM> wrote > I knew it!! If this chip were really a server, wouldn't it have it's own IP > addy? instead of it being eternity.cs.umass.edu PORT 9080. And for the FTP > server he supposedly stuck on the chip -- that alone would require a few KB's. I'm skeptical myself but the above is not the reason. Many user-implemented servers (of all kinds) use port numbers out of the "privileged port" range because of local firewalling. Do we know that eternity is not the name assigned to the iPic? Even if eternity is a separate TCP/IP host, this does not preclude layer 3 switching or even a smart router from directing traffic to a separate physical host based on the port number. Obviously, some corroboration is required before anyone really believes this but I'm rooting for the little fellow. :) -greg "pollyanna" wiley

Adam, I have'nt looked at the site but the current Circuit Cellar magazine (#108) has an article about a stripped-down TCP/IP stack implemented in a PIC12C672 for remote sensing on the internet. - Tom At 04:54 PM 7/14/99 -0400, Adam Davis wrote: >Well... I'm a bit skeptical. Mind you, I've not implemented a tcp/ip stack >anywahere, nevemind on a pic, but he has code that: > >Handles 115200 serial reception and transmission >Handles and serves data from an eeprom >With a fully tcp/ip stack and http 1.0 server between the two >On a chip running at 4MHz. > >To my knowledge, none of the 12cxxx chips have usart, so he must be bit >banging. Probably no error correction. He could be doing a funny interrupt on {Quote hidden}>change and timer combination for reception... > >I suppose it is possible, but I only say that because I don't know as much as >I'd like to know about the tcp/ip stack, which is the kicker, here... > >-Adam > >Matt Bennett wrote: >> >> I don't think anyone has mentioned this in the past few seconds... >> >> This was just posted on slashdot: >> >> slashdot.org/articles/99/07/14/1937221.shtml >> >> "Jason Asbahr writes " From the wearables list, Shrikumar wrote: >> I'd like to announce what is a really tiny implementation of >> TCP/IP stack and a really really tiny web-server. " >> >> Which contains a pointer to: >> >> http://www-ccs.cs.umass.edu/~shri/iPic.html >> >> Matt Bennett

Hi Tom, The Circuit Cellar version doesn't implement TCP. It implements UDP/IP over PPP. In fact, it doesn't even implement a fully RFC-compliant version of that. Nonetheless, it's an impressive feat. This is why I *strongly* suspect that the device mentioned on slashdot doesn't do what the author claims. TCP is a *lot* (ie. order of magnitude) more complex than UDP, and, among other things, requires a copy of un-ACK'd data to be kept for resending (in the event of a lower-level IP packet going astray). Since the PIC sure as hell doesn't have space for this, is he storing this data on the EEPROM? Not a good idea if you have a limited write-cycle lifespan. I'm particularly impressed by his codesize breakdown - apparently HTTP/1.0 and I2C can be implemented in 3~99 instructions. Does this mean between 3 and 99 instructions? I'd like to meet the guy who can implement HTTP and I2C in 3 instructions. UDP+TCP in 70~99? If it's 99 instructions, it ain't TCP (at least not in any meaningful sense). Cheers, Ben Tom Handley wrote: {Quote hidden}> > Adam, I have'nt looked at the site but the current Circuit Cellar magazine > (#108) has an article about a stripped-down TCP/IP stack implemented in a > PIC12C672 for remote sensing on the internet. > > - Tom > > At 04:54 PM 7/14/99 -0400, Adam Davis wrote: > >Well... I'm a bit skeptical. Mind you, I've not implemented a tcp/ip stack > >anywahere, nevemind on a pic, but he has code that: > > > >Handles 115200 serial reception and transmission > >Handles and serves data from an eeprom > >With a fully tcp/ip stack and http 1.0 server between the two > >On a chip running at 4MHz. > > > >To my knowledge, none of the 12cxxx chips have usart, so he must be bit > >banging. Probably no error correction. He could be doing a funny > interrupt on > >change and timer combination for reception... > > > >I suppose it is possible, but I only say that because I don't know as much as > >I'd like to know about the tcp/ip stack, which is the kicker, here... > > > >-Adam > > > >Matt Bennett wrote: > >> > >> I don't think anyone has mentioned this in the past few seconds... > >> > >> This was just posted on slashdot: > >> > >> slashdot.org/articles/99/07/14/1937221.shtml > >> > >> "Jason Asbahr writes " From the wearables list, Shrikumar wrote: > >> I'd like to announce what is a really tiny implementation of > >> TCP/IP stack and a really really tiny web-server. " > >> > >> Which contains a pointer to: > >> > >> http://www-ccs.cs.umass.edu/~shri/iPic.html > >> > >> Matt Bennett

Ben, thanks for clarifying that. I had only glanced at the article and noticed the author said he had to `cut a lot of corners' for the project. It is an interesting project for remote monitoring with a PIC. The normal approach is an embedded PC which drives up the cost. I'm a novice when it comes to implementing TCP/IP. - Tom At 12:05 AM 7/15/99 -0700, Ben Stragnell wrote: {Quote hidden}>Hi Tom, > >The Circuit Cellar version doesn't implement TCP. It implements UDP/IP >over PPP. In fact, it doesn't even implement a fully RFC-compliant >version of that. > >Nonetheless, it's an impressive feat. This is why I *strongly* suspect >that the device mentioned on slashdot doesn't do what the author claims. > >TCP is a *lot* (ie. order of magnitude) more complex than UDP, and, >among other things, requires a copy of un-ACK'd data to be kept for >resending (in the event of a lower-level IP packet going astray). Since >the PIC sure as hell doesn't have space for this, is he storing this >data on the EEPROM? Not a good idea if you have a limited write-cycle >lifespan. > >I'm particularly impressed by his codesize breakdown - apparently >HTTP/1.0 and I2C can be implemented in 3~99 instructions. Does this mean >between 3 and 99 instructions? I'd like to meet the guy who can >implement HTTP and I2C in 3 instructions. UDP+TCP in 70~99? If it's 99 >instructions, it ain't TCP (at least not in any meaningful sense). > >Cheers, >Ben > >Tom Handley wrote: >> >> Adam, I have'nt looked at the site but the current Circuit Cellar magazine >> (#108) has an article about a stripped-down TCP/IP stack implemented in a >> PIC12C672 for remote sensing on the internet. >> >> - Tom

Ben Stragnell <RemoveMEspareTakeThisOuTCODEPUPPIES.COM> wrote: > I'm particularly impressed by his codesize breakdown - apparently > HTTP/1.0 and I2C can be implemented in 3~99 instructions. Does this mean > between 3 and 99 instructions? I'd like to meet the guy who can > implement HTTP and I2C in 3 instructions. UDP+TCP in 70~99? If it's 99 > instructions, it ain't TCP (at least not in any meaningful sense). Someone pointed out that it uses a different TCP port number for each web page that it can serve up. It seems remotely possible that he could have done a non-RFC-compliant "TCP" which only listens for connections on certain ports, doesn't actually pay any attention to incoming data, and shoves a different set of fixed data back for each port number. Rather than calling such a thing an implementation of TCP, I think it might be more reasonable to call it TCP-spoofing. However, even doing that kind of hack would probably take a lot more code than he is claiming, so I still think the thing is a hoax.

Well, I perused RFC 1122 which states: An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant". And I don't think that the server implements all the MUST requirements, of which there are over 140. It looks like what he has done is create a device which responds to ip commands by reading the port number the command was sent to, and delivering some of the contents of the eeprom based on the port number. I wonder, however, how it deals with packets not meant for it's IP. Since it's directly off a computer acting as a router, it only gets packets meant for it's IP. It may very well be that it ignores the IP, assuming whatever it is belongs to it, and reads the port and the IP to send the results to. It would then be an easy matter to form a legitimate packet to send to the router. But until we see the code, it's a matter of speculation. I don't doubt that it could be done, but I doubt that it could be fully compliant, as stated, and only fit in 256 words of program memory. However, the neat thing is that it brought down some of the blocks for me that make me think that a TCP/IP stack on a pic is a near impossibility.... -Adam Matt Bennett wrote: {Quote hidden}> > I don't think anyone has mentioned this in the past few seconds... > > This was just posted on slashdot: > > http://slashdot.org/articles/99/07/14/1937221.shtml > > "Jason Asbahr writes " From the wearables list, Shrikumar wrote: > I'd like to announce what is a really tiny implementation of > TCP/IP stack and a really really tiny web-server. " > > Which contains a pointer to: > > http://www-ccs.cs.umass.edu/~shri/iPic.html > > Matt Bennett