I have implemented TCP/IP (well actually UDP/IP) from the hardware up on
X86. A moderate complete implementation (in "C") uses about:

Code (16-bit x86): 16KBytes
Data: about 12K minimum

This stack implements ARP, IP, ICMP and UDP, but _not_ TCP, PPP or SLIP (it
runs on ethernet).

Seems a bit large for a PIC.

btw: please don't ask for a copy - I wrote this for hire and can not
distibute it  :-(

Bob Ammerman
RAm Systems
(high function, high performance, low level software)

----- Original Message -----
From: William Chops Westfield <billw@CISCO.COM>
To: <PICLIST@MITVMA.MIT.EDU>
Sent: Tuesday, May 30, 2000 3:03 AM
Subject: Re: [EE] Embedded Internet enabling methods: Which?


>     I just wish there was a free full TCP/IP implementation out there for
>     the PIC :)  I dread having to write my own.
>
>     I've looked at the previously mentioned implementations, not with too
>     much detail but they seem to have certain problems.. such as you
>     mentioned.. hardware based or limited features. I want an API library
>     where I can use standard library calls like in unix to program my
>     application.
>     I don't want to only be able to use certain ports, or have to connect
>     via a ppp/slip link.. Let me know if you find anything like this..
>
> IMO (not very humble - I've got a fair amount of experience in this area),
> this isn't possible.  To start with, the protocols pretty much assume an
> environment with "separate" operating system and applications, which will
> get you to pretty large code (for the "OS" side, which has to have
> "everything") pretty quick.  Implementing Internet connectivity on a small
> microcontroller means cheating.  How badly you cheat, and where, and
whether
> you'll be able to get away with it on a large scale, is dependent on how
> much space you're willing to sacrifice to the network code (and it IS
> primarilly a space issue, rather than a speed issue.)
>
> Possible approaches with "minimal" cheating:
>
> 1) Code-generator type scheme, where your code is carefully analyzed,
>    and a "custom Network OS" is generated that implements ONLY those parts
>    of the stack that you actually use.
>
> 2) an interpretter (basic-stamp-like, I guess) with a very large external
>    memory... (here, performance might start to be an issue, of course.  An
>    interpretted OS with applications written in assembly.  Weird.)
>
> As a reference or starting point, you might consider NCSA telnet, an "open
> source" (but predating that term) application/OS/Internet stack that runs
on
> DOS.  a 1990 ("pre-bloat but post-64k-frugal") implementation has a
> "minitel.exe" program without too much extra stuff (like tektronix
terminal
> emulators) and is about 93kbytes (for the exe file.)  Other possibilities
> include "ka9q" - a similar project targetted (restricted?) to ham radio
> applications.
>
> BillW