ARM9 TCP/IP Stack

Hey y'all --

I'm throwing this post out on behalf of my poor beleagured programmer.
We're starting to migrate over our new designs from using the Lantronix
XPort for our network needs to an ARM9 with an onboard MAC (NXP
LPC3250) and handling the network in software.

The goals is going to be to keep things small; I'd love to manage to
consistently keep code+data in the on-die RAM (256K) rather than having
to throw away board space and routing for external RAMs.  We'll
primarily be running a fairly limited web server, a shell login for
any of the real work, MAYBE an ftp server that'll come into play once
in a blue moon.  There's also been some discussion of also running an
SSL layer, but I'm not convinced that security wouldn't be better
handled in a $60 external box from Linksys.

Generally throughput's not going to be a major issue for us, but
robustness is. Ideally, no matter how badly overloaded with requests we
may be, I'd like to gracefully reject the requests rather than dying
horribly and having to resort to the watchdog timer resetting the world.

We're building on GNU tools and, what with trying to keep to the local
RAM, running Linux or godforbid CE isn't at all a thought.  Most likely
we'll be running either FreeRTOS or for(;;) {...}.

So the TCP/IP stacks I've found that seem to want to play nicely in
that context are lwip and uIP.  Does anyone have, ideally, any
experience with both and some thoughts on their relative merits?  Or
experience with one or the other and things to say?  Or thoughts on the
entire exercise at large?

Thanks,
Rob

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

The CMX stacks seems to perform nicely, and don't use too much space.



"Rob Gaddi" <rgaddi@technologyhighland.com> wrote in message 
news:20100222094345.00005a2f@unknown...
> Hey y'all --
>
> I'm throwing this post out on behalf of my poor beleagured programmer.
> We're starting to migrate over our new designs from using the Lantronix
> XPort for our network needs to an ARM9 with an onboard MAC (NXP
> LPC3250) and handling the network in software.
>
> The goals is going to be to keep things small; I'd love to manage to
> consistently keep code+data in the on-die RAM (256K) rather than having
> to throw away board space and routing for external RAMs.  We'll
> primarily be running a fairly limited web server, a shell login for
> any of the real work, MAYBE an ftp server that'll come into play once
> in a blue moon.  There's also been some discussion of also running an
> SSL layer, but I'm not convinced that security wouldn't be better
> handled in a $60 external box from Linksys.
>
> Generally throughput's not going to be a major issue for us, but
> robustness is. Ideally, no matter how badly overloaded with requests we
> may be, I'd like to gracefully reject the requests rather than dying
> horribly and having to resort to the watchdog timer resetting the world.
>
> We're building on GNU tools and, what with trying to keep to the local
> RAM, running Linux or godforbid CE isn't at all a thought.  Most likely
> we'll be running either FreeRTOS or for(;;) {...}.
>
> So the TCP/IP stacks I've found that seem to want to play nicely in
> that context are lwip and uIP.  Does anyone have, ideally, any
> experience with both and some thoughts on their relative merits?  Or
> experience with one or the other and things to say?  Or thoughts on the
> entire exercise at large?
>
> Thanks,
> Rob
>
> -- 
> Rob Gaddi, Highland Technology
> Email address is currently out of order 

Hi Rob,

Rob Gaddi wrote:
> I'm throwing this post out on behalf of my poor beleagured programmer.

What?  He/she doesn't have USENET access?  ;-)

> We're starting to migrate over our new designs from using the Lantronix
> XPort for our network needs to an ARM9 with an onboard MAC (NXP
> LPC3250) and handling the network in software.
> 
> The goals is going to be to keep things small; I'd love to manage to
> consistently keep code+data in the on-die RAM (256K) rather than having
> to throw away board space and routing for external RAMs.  We'll
> primarily be running a fairly limited web server, a shell login for
> any of the real work, MAYBE an ftp server that'll come into play once
> in a blue moon.  There's also been some discussion of also running an
> SSL layer, but I'm not convinced that security wouldn't be better
> handled in a $60 external box from Linksys.

Have you identified *exactly* the sort of (network) environment
you are targeting?  E.g., benevolent, benign, adversarial or hostile?

Have you quantified the number of each type(s) of client(s) that
need to be supported for each service?  E.g., if you have to support
N clients on M TCP-based services, then you have M persistent
connections to maintain, etc.  Can you, perhaps, arrange for
certain services to be unavailable when *other* services are
running (e.g., run FTPd *or* HTTPd but not both?)?  Can you
use lighter weight services (e.g., TFTP vs. FTP)?

UDP services tend to be more economical to implement than
TCP based services.  If you can do away with TCP entirely,
then you can significantly trim the network stack.

What sort of a *shell* do you expect to support (i.e., what
sort of "command line" do you expect the user to interact with
and might that not better be served via a web interface?  Or,
vice versa?)

What resources does the "rest" of your application require?
E.g., if you need 200K to service the application's "real"
purpose in life, then you really only have 56K "left over"
to play in.

> Generally throughput's not going to be a major issue for us, but
> robustness is. Ideally, no matter how badly overloaded with requests we
> may be, I'd like to gracefully reject the requests rather than dying
> horribly and having to resort to the watchdog timer resetting the world.

If you *really* want to economize on resources (I don't know what
sort of TEXT space you have available), you have to bastardize the
traditional layering of the network stack and move some of the
higher level functions further down into the stack.  E.g., so
you don't end up buffering packets for services that *won't*
(can't) start, etc.

You can also simplify things like ICMP support, routing, etc.
Again, all this depends on your application domain and the
sort of environment that you intend to operate within.

> We're building on GNU tools and, what with trying to keep to the local
> RAM, running Linux or godforbid CE isn't at all a thought.  Most likely
> we'll be running either FreeRTOS or for(;;) {...}.
> 
> So the TCP/IP stacks I've found that seem to want to play nicely in
> that context are lwip and uIP.  Does anyone have, ideally, any
> experience with both and some thoughts on their relative merits?  Or
> experience with one or the other and things to say?  Or thoughts on the
> entire exercise at large?

You may find it wiser to bastardize one of these stacks (or, roll
your own -- they aren't hard *if* you know what's involved) to
better fit your needs.  Off the shelf solutions try to be
lots of things to lots of people and, as a result, are never
*perfect* fits for any *particular* use.

If you *don't* understand the network protocols, then just
"plugging them in" is bound to be an inefficient (in terms
of recurring resources) exercise.

Rob Gaddi <rgaddi@technologyhighland.com> wrote in 
news:20100222094345.00005a2f@unknown:

> We're building on GNU tools and, what with trying to keep to the local
> RAM, running Linux or godforbid CE isn't at all a thought.  Most 
likely
> we'll be running either FreeRTOS or for(;;) {...}.
> 
> So the TCP/IP stacks I've found that seem to want to play nicely in
> that context are lwip and uIP.  Does anyone have, ideally, any
> experience with both and some thoughts on their relative merits?  Or
> experience with one or the other and things to say?  Or thoughts on 
the
> entire exercise at large?

Sorry, don't have experience with both.  I can say that I was in a 
similar situation a few months back and looked at lwIP, uIP, uC/IP, 
Ethernut and others.  

I decided that lwip looked more complete, flexible and robust, and it 
had a license I was happy with.  It's also well-documented and has an 
active support / developer community.  Finally, it's not tied into a 
particular operating system.  

uC/IP, uIP seem quite limited, have little documentation and no active 
developer community.  Ethernut (NutNet) seemed pretty full-functioned 
and robust but it's closely tied to a particular operating system 
environment (Nut/OS).  Then there are a number of others that are 
commercial (i.e. pay $$).

I went with lwip.  It ported easily into my system (mine is OS-less but 
there are apparently many people running lwip on various RTOSes 
including FreeRTOS).  I then developed a driver for my NIC -- not 
trivial but the interface to lwip is very straightforward.  I've been 
quite happy with lwip.