On Fri, 7 Sep 2001, Byron A Jeff wrote:

> It's starting to look like I'll have to deliver a UDP/ICMP/IP stack on a
> 12C509 before anyone will believe that the cost of the stack isn't that
> significant. Would anyone like to take a crack at defining a usable
> specification for such a project?

I'm most of the way there.  My original target was a 16F84, which has a
little less RAM than the '509.  I was going for TCP/IP with ICMP and HTTP
originally, but later figured out all I needed was UDP, and maybe some
very limited ICMP.  Maybe we should get together and compare notes...  It
may be a while before I can do anything serious with it, though, as we're
moving to a new house and I'm trying to put a couple of other (paying)
projects to bed.  Maybe a nice winter project?

What I currently have in mind would be a set of C functions that would
implement Layer 3 (IP), and another set for each L4 protocol...  so you
could #include UDP, ICMP, TCP, whatever you happen to need without any
interdependencies.  The biggest fault I see with the existing
implementations is that the layers are very tightly integrated; there's
usually PPP or SLIP code shuffled amongst the IP and TCP stuff, and it's
got HTTP stuff poured over it and oozing throughthe cracks.  I want to
separate it into the layers like it should be,and do it without burning a
bazillion words of program space.

The only real problem I see with this approach?  If you go with Ethernet
using, say, a Crystal CS89xx chip, you can use all of its buffer space and
vastly reduce the PIC RAM requirements.  For PPP or SLIP or whatever else
you don't have that luxury.  I can think of a few ways around this:

  1. Have another set of standard functions to read and write bytes to
buffer space.  These functions would need to be modified to fit your
environment - either talk to the Crystal chip or use RAM buffers, or
external EEPROM or whatever.  Messy and a lot of work.
  2. Define a minimum standard hardware environment with some sort of
external memory, used regardless of the situation.  This is a crappy
solution, in my opinion, and defeats a lot of the intent of writing a
general purpose code base for cheapskates and lazy people (like me).
  3. Use #defines and #ifs to build one set of functions that will handle
buffers no matter what you're doing.  You then #define the hardware
environment (maybe CS8900, EEPROM or INTERNAL) and let the compiler
generate the code to meet whatever the situation requires.  This is the
most appealing -- a lot of work up front, but saves tons of work in the
end.

Maybe I'm being too ambitious, but I want to write a code set exactly
once, that I can re-use without modification anywhere, any time, and
preferably on any processor.

Dale
--
Hallo, this is Linus Torvalds and I pronounce Linux as Leennuks.
Hallo, this is Bill Gates and I pronounce 'crap' as 'Windows'.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body