1. Home
  2. Embedded Programming
  3. ARM9 TCP/IP Stack

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
Reply to
Rob Gaddi
Loading thread data ...

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

Reply to
Peter Seldon

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

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.

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.

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.

Reply to
D Yuniskis

Rob Gaddi wrote in news:20100222094345.00005a2f@unknown:

likely

the

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.

Reply to
Jeff Barber

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.