Searching \ for 'From slashdot- TCPIP on a PIC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'From slashdot- TCPIP on a PIC'.

Truncated match.
PICList Thread
'From slashdot- TCPIP on a PIC'
1999\07\14@162604 by Matt Bennett

flavicon
face
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

1999\07\14@165551 by Adam Davis

flavicon
face
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}

1999\07\14@165807 by Andy Kunz

flavicon
face
>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_OUTandyTakeThisOuTspamrc-hydros.com      http://www.rc-hydros.com     - Race Boats
.....andyKILLspamspam@spam@montanadesign.com  http://www.montanadesign.com - Electronics
==================================================================

1999\07\14@170217 by Tim Hamel

picon face
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,
adavisspamKILLspamBALADYNE.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
>

1999\07\14@171253 by Adam Davis

flavicon
face
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}

1999\07\14@171718 by John Mitchell

flavicon
face
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}

:)


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

1999\07\14@172331 by Tim Hamel

picon face
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, johnmspamspam_OUTMAGNET.COM
writes:

{Quote hidden}

1999\07\14@173210 by Adam Davis

flavicon
face
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}

1999\07\14@174702 by Greg Wiley

picon face
Tim Hamel <KILLspamIMDNICE12KILLspamspamAOL.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

1999\07\14@181232 by Dan Larson

flavicon
face
Anyone have a look at the new TCP/IP chip
from Seiko?  It was featured the latest
Electronic Products on page 74.

S7600A

http://www.seiko-usa-ecd.com

1999\07\15@011629 by Tom Handley

picon face
  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}

1999\07\15@030809 by Ben Stragnell

flavicon
face
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}

1999\07\15@095642 by Tom Handley

picon face
  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}

magazine
>> (#108) has an article about a stripped-down TCP/IP stack implemented in a
>> PIC12C672 for remote sensing on the internet.
>>
>>    - Tom

1999\07\15@145723 by Eric Smith

flavicon
face
Ben Stragnell <RemoveMEspareTakeThisOuTspamCODEPUPPIES.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.

1999\07\15@150940 by Bob Blick

face
flavicon
face
I notice Slashdot pulled the article off their page just a couple of hours
after it was put up, which reinforces the hoax idea.

Probably in a day or two we'll hear the real story.

-Bob

1999\07\15@152150 by Tim Hamel

picon face
Or maybe Slashdot was Slashdotted? <g> I can't wait to hear the REAL story.

Tim H.


In a message dated 7/15/99 12:10:01 PM Pacific Daylight Time, spamBeGonebobspamBeGonespamTED.NET
writes:

> I notice Slashdot pulled the article off their page just a couple of hours
>  after it was put up, which reinforces the hoax idea.
>
>  Probably in a day or two we'll hear the real story.
>
>  -Bob

1999\07\16@115832 by Adam Davis

flavicon
face
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}

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...