[ECOS] TCP/IP Stack for ECOS

[ECOS] TCP/IP Stack for ECOS

[Ramana]

Hi,
Does any body know of a tcp/ip stack for ecos.
Thanks
Ramana B.V

Re: [ECOS] TCP/IP Stack for ECOS

[Jonathan Larmour]

Ramana wrote:
> 
> Hi,
> Does any body know of a tcp/ip stack for ecos.

We have some third-party partners who supply these for most of the ports.
The companies are EBS http://www.etcbin.com/ and Pacific Softworks
http://www.pacificsoftworks.com/

Hope this helps,

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

[ECOS] TCP/IP Stack for eCos.

[Prakash R]

We plan to port BSD-4.4lite's TCP/IP stack on eCos. Currently we are
trying to get the eCos to run on our MPC860 based board. Once we are
through with that we would be porting TCP/IP stack on eCos. I request
the people interested to get in touch, so that we can share our
expertise/experience.

We are also looking into RTEMS to find out how TCP/IP has been
implemented onto RTEMS.

-- 
Prakash R	
Co-ordinating Engineer, Internet Telephony Group
===========================================================================
C-DOT (Centre for Development of Telematics)	
71/1, Sneha Complex, Miller Road, Bangalore - 560052, India
Email:rprakash@cdotb.ernet.in, Phone:+91-80-2263399, Fax:+91-80-2263256 
===========================================================================

Re: [ECOS] TCP/IP Stack for eCos

[Jay Lepreau]

	> It probably would take very little effort to get the OSKit's TCP/IP
	> stack working in eCos, [...]

	Do you know if it's a zero copy stack?

Yes, I believe it is but can't swear to it.  It's FreeBSD's
implementation with our wrapping code and environment.

Aside:
In Sec 5 of the SOSP paper on our site there's a discussion of a
networking example (ttcp) which might be enlightening in a general
way.  In that particular example an extra copy is incurred on the
outgoing path because BSD's scatter/gather `mbufs' in the protocol
component have to be copied into linear `skbuffs' in the (unchanged)
Linux driver component.  That is an artifact of the mismatch and would
not apply if you allowed yourself to change the Linux drivers or
provided other drivers.  (For maintenance and philosophical reasons,
we generally avoid changing foreign "encapsulated" code in the OSKit.)

Re: [ECOS] TCP/IP Stack for eCos

[Fred Fierling]

Jay Lepreau wrote:

>         > It probably would take very little effort to get the OSKit's TCP/IP
>         > stack working in eCos, [...]

I assume it's written in C?

It occurs to me that since eCos is written in C++ that it may be
an idea to write its TCP/IP stack in C++ as well.  Thoughts?

Re: [ECOS] TCP/IP Stack for eCos

[Brendan Simon]

It depends who is going to maintain the networking stack.  It probably makes sense
to maintain some C++ wrapper classes to an existing and maintained IP stack (eg.
FreeBSD, Linux, etc).

Brendan Simon.


Fred Fierling wrote:

> Jay Lepreau wrote:
>
> >         > It probably would take very little effort to get the OSKit's TCP/IP
> >         > stack working in eCos, [...]
>
> I assume it's written in C?
>
> It occurs to me that since eCos is written in C++ that it may be
> an idea to write its TCP/IP stack in C++ as well.  Thoughts?

Re: [ECOS] TCP/IP Stack for eCos

[Fernando D. Mato Mira]

At 05:06 PM 5/4/99 -0700, you wrote: 
>Jay Lepreau wrote: 
> 
>> > It probably would take very little effort to get the OSKit's TCP/IP 
>> > stack working in eCos, [...] 
> 
>I assume it's written in C? 
> 
>It occurs to me that since eCos is written in C++ that it may be 
>an idea to write its TCP/IP stack in C++ as well. Thoughts?

No. Even if there was egcs support for Analog Devices and TI 
DSPs at least, egcs is not like Green Hills EC++ where you 
can span the continuum between EC++ and C++ by switching 
on/off features.
Most of our projects run on raw hardware because a kernel 
is not needed, even if there're multiple tasks running (eg: network, 
infrared in/out, audio in/out, video in, keyboard, display, `stuff').




Fernando D. Mato Mira                                                        
Real-Time SW Engineering & Networking
Advanced Systems Engineering Division                                                               
CSEM - Centre Suisse d'Electronique et de Microtechnique 
Jaquet-Droz 1                                                                    Email:   matomira AT acm DOT org
CH-2007 Neuchatel                                                            Phone:    +41 (32) 720-5157
Switzerland                                                                       FAX:        +41 (32) 720-5720

http://www.csem.ch/         http://www.vrai.com/          http://ligwww.epfl.ch/matomira.html

Re: [ECOS] TCP/IP Stack for eCos

[Jay Lepreau]

> Is anyone interested in working on an open TCP/IP stack for eCos?

It probably would take very little effort to get the OSKit's TCP/IP
stack working in eCos, because one of the OSKit's goals is that each
component not only be entirely separable and optional, but be able to
fit into *other* operating systems and environments.

Copious docs, examples, papers and source available at
http://www.cs.utah.edu/flux/oskit/ .

Examples of fitting in to other envs:
Outside people have used it to get a "Scheme computer" running in a
few hours.  We've done the same for Java (you can boot Kaffe on bare
hardware).  Outside people have used the device drivers and low-level
code in a number of their own x86 kernels.

Although some of the low-level OSKit components contain x86 or
PC-specific code, a large number of the 31 component libraries are
high level and should work on any architecture.  Besides networking,
of interest might be BOOTP, posix-like libraries, pthreads, BSD and
Linux-supported filesystems, simple virtual memory, and some research
products in thread scheduling and network link scheduling.  All the
Linux devices drivers are there.

It's written in C, uses autoconf, the GNU toolchain, supports ELF and
a.out on the x86.  Many components export the COM object model (scary
sounding I know, but it's really just a glorified function table, so
it's fast).  You can debug on top of Unix or use remote gdb.  In some
ways eCos and the OSKit overlap but in more ways they are complementary.
Good things could be done with them together.

Jay Lepreau
University of Utah


p.s. Hi Stan, long time no see-- you wouldn't recognize the
4th east penthouse any more!

Re: [ECOS] TCP/IP Stack for eCos

[Fred Fierling]

Jay Lepreau wrote:

> > Is anyone interested in working on an open TCP/IP stack for eCos?
>
> It probably would take very little effort to get the OSKit's TCP/IP
> stack working in eCos, [...]

Do you know if it's a zero copy stack?

Re: [ECOS] TCP/IP Stack for eCos

[Fernando D. Mato Mira]

At 05:54 PM 4/27/99 +0700, you wrote:
>On Tue, 27 Apr 1999 11:07:53 -0700, Fred Fierling wrote:
>
>>A TCP stack that doesn't use malloc? Interesting. Do
>>you forbid malloc to avoid problems like memory
>>leaks, to guarantee response time, or why?
>
>Perhaps to help in provability? (Ie. guaranteeing the system is valid.)
>I expect you could still use buffer pools, instead of a single generic
>malloc that handles allocations for all types. In C++ you could use a
>class-specific operator new and a private heap for each type.

Deterministic response time. 

Some platforms that we use lack C++ compilers (eg, Analog Devices' SHARC DSP) .
In addiion to that, we could be restricted
to 544 Kbits of RAM (so the maximum program size would be 8K words of
48-bit instructions (leaving aside 8K 40-bit words for data)). That's a $10 DSP.
We just used the non-low-power version where we had the luxury of 1Mbit SRAM
inside. Among several other things, we had networking in it (custom, not IP).




Fernando D. Mato Mira                                                        
Real-Time SW Engineering & Networking
Advanced Systems Engineering Division                                                               
CSEM - Centre Suisse d'Electronique et de Microtechnique 
Jaquet-Droz 1                                                                    Email:   matomira AT acm DOT org
CH-2007 Neuchatel                                                            Phone:    +41 (32) 720-5157
Switzerland                                                                       FAX:        +41 (32) 720-5720

http://www.csem.ch/         http://www.vrai.com/          http://ligwww.epfl.ch/matomira.html

Re: [ECOS] TCP/IP Stack for eCos

[Kenneth Porter]

On Tue, 27 Apr 1999 11:07:53 -0700, Fred Fierling wrote:

>A TCP stack that doesn't use malloc? Interesting. Do
>you forbid malloc to avoid problems like memory
>leaks, to guarantee response time, or why?

Perhaps to help in provability? (Ie. guaranteeing the system is valid.)
I expect you could still use buffer pools, instead of a single generic
malloc that handles allocations for all types. In C++ you could use a
class-specific operator new and a private heap for each type.


Kenneth Porter
Kensington Laboratories, Inc.
mailto:kenneth_porter@kensingtonlabs.com
http://www.kensingtonlabs.com

RE: [ECOS] TCP/IP Stack for eCos

[Leonard, Niall]

Which processors are you currently poring eCos to ?

> -----Original Message-----
> From:	Bart Veer [SMTP:bartv@cygnus.co.uk]
> Sent:	Monday, April 26, 1999 3:02 PM
> To:	fff@microplex.com
> Cc:	ecos-discuss@cygnus.com
> Subject:	Re: [ECOS] TCP/IP Stack for eCos
> 
> >>>>> "Fred" == Fred Fierling <fff@microplex.com> writes:
> 
>     Fred> Is anyone interested in working on an open TCP/IP stack for
>     Fred> eCos?
> 
> Cygnus would very much like to see this happen. If nobody else does it
> then sooner or later we will end up doing a port of a suitable stack
> ourselves, but right now we are busy porting to various processors and
> have little spare bandwidth. However we should be able to assist any
> net effort, and several of the team members have experience with
> embedded TCP/IP stacks.
> 
> Bart Veer // eCos net maintainer

[ECOS] TCP/IP Stack for eCos

[Fred Fierling]

Is anyone interested in working on an open TCP/IP stack
for eCos?

--
Fred Fierling                           Tel: +1 604 444-1717
Microplex Systems Ltd.                  Fax: +1 604 444-4239
8525 Commerce Court                 mailto:fff@microplex.com
Burnaby, BC   V5A 4N3               http://www.microplex.com/

Re: [ECOS] TCP/IP Stack for eCos

[Bob Cousins]

Hi Fred Fierling,

>Is anyone interested in working on an open TCP/IP stack
>for eCos?

I'm certainly interested, but I I don't think eCos is ported to any of the
targets I'm interested in, so my first task is to do or wait for such ports. I
would primarily be interested in using an OS like eCos for network applications,
so it's chicken and egg!

I recently worked on a TCP/IP stack for Hitachi processors using HI-OS (ITRON
based OS), and got quite far developing it on a PC under Windows. The few OS
calls the stack makes were handling by a library which made calls into Windows.
There was no hardware emulation or pre-emptive tasking, but this was not a great
problem. I wrote a PPP driver for it which could have used the PC serial port,
but I ended up using an internal loopback.

I studied various stacks around and although Unix stacks like BSD would be more
robust and mature, if I was picking a free stack I'd take a close look at the
Xinu stack. It has several bugs (which are partly documented), as it has not had
the benefit of widespread support. Assuming you are going to have to read the
RFCs and study other stacks anyway, it at least gives a step up on writing from
scratch.


-- 
Bob Cousins, Software Engineer.
http://www.lintilla.demon.co.uk/
"We demand that we may, or may not, be philosophers!"

Re: [ECOS] TCP/IP Stack for eCos

[Fred Fierling]

Bob Cousins wrote:

> I studied various stacks around and although Unix stacks like BSD would be more
> robust and mature, if I was picking a free stack I'd take a close look at the
> Xinu stack.

Is Xinu a zero copy stack (i.e. only passes pointers)?  This is important
because an RTOS often runs on wimpy hardware.

Re: [ECOS] TCP/IP Stack for eCos

[Bob Cousins]

Hi Fred Fierling,

>Is Xinu a zero copy stack (i.e. only passes pointers)?  This is important
>because an RTOS often runs on wimpy hardware.

Ah, now we're talking requirements. Data buffering is a topic by itself ;-) Xinu
isn't zero copy, but it is fairly easy to change. I designed a stack based
around a flexible buffer structure similar to the Unix mbuf. Adding this type of
thing to Xinu/TCP would be more work, changing all the references etc,
rethinking the fragmentation/reassembly. 

The way I see it is that Xinu/TCP is a fairly close fit which more or less works
and provides a fairly clean base architecture to work on, and would provide a
quick way to get something working. (In comparison to other stacks I know of
such as FreeBSD, Linux, KA9Q, WATTCP et al). This could then be developed to
revise the architecture and implement better performance etc.

I'm afraid I'm on sketchy ground here as I'm not familiar with eCos or its
current targets. My typical requirement is for a networked data acquisition
unit, ideally running SNMP, but at least capable of UDP over ethernet. A PC386
card is probably too expensive but the software would be easy for me to put
together. Something smaller should do, the data acquisition is trivial, it could
be done with a PIC and UDP at a stretch, but SNMP out of the question, so I'm
thinking 8051 variant. Xinu is attractive because it is simple and has SNMP code
too. Unfortunately I've little time or money to persue either vigorously at the
moment, so this is a background activity.
-- 
Bob Cousins, Software Engineer.
http://www.lintilla.demon.co.uk/
"We demand that we may, or may not, be philosophers!"

Re: [ECOS] TCP/IP Stack for eCos

[Frank W. Miller]

> >Is Xinu a zero copy stack (i.e. only passes pointers)?  This is important
> >because an RTOS often runs on wimpy hardware.
> 

XINU is not a zero copy stack.  There are two copies on the way up and on
the way down.


> isn't zero copy, but it is fairly easy to change. I designed a stack based

I would differ with you on this.  Getting it right would not be a trivial
task.


> The way I see it is that Xinu/TCP is a fairly close fit which more or less
> works and provides a fairly clean base architecture to work on, and would
> provide a quick way to get something working. (In comparison to other stacks
> I know of such as FreeBSD, Linux, KA9Q, WATTCP et al). This could then be
> developed to revise the architecture and implement better performance etc.
> 

All of these stacks are quite stable and work well. The *BSD stack is by
far the highest performance platform and arguably the best documented in
Wright and Stevens books.  The others are all comparable since they do
similar copying.  KA9Q has probably the smallest footprint.  You will
probably want to look at the FreeBSD TCP port to RTEMS.  A lot of the
issues in moving that stack to an RTOS are addressed there.

Later,
FM


--
Frank W. Miller
Cornfed Systems Inc
www.cornfed.com

Re: [ECOS] TCP/IP Stack for eCos

[Bart Veer]

>>>>> "Fred" == Fred Fierling <fff@microplex.com> writes:

    Fred> Is anyone interested in working on an open TCP/IP stack for
    Fred> eCos?

Cygnus would very much like to see this happen. If nobody else does it
then sooner or later we will end up doing a port of a suitable stack
ourselves, but right now we are busy porting to various processors and
have little spare bandwidth. However we should be able to assist any
net effort, and several of the team members have experience with
embedded TCP/IP stacks.

Bart Veer // eCos net maintainer

Re: [ECOS] TCP/IP Stack for eCos

[Fernando D. Mato Mira]

At 03:02 PM 4/26/99 +0100, you wrote:
>>>>>> "Fred" == Fred Fierling <fff@microplex.com> writes:
>
>    Fred> Is anyone interested in working on an open TCP/IP stack for
>    Fred> eCos?

We are looking around right now because we want to have an embedded
TCP/IP stack usable in a variety of contexts, particularly on raw processors/controllers/DSPs
w/o an OS, and in cases where malloc is explicitly and formally forbidden.
If such an effort were covered by a BSD-style license we would very
probably join in.

Fernando D. Mato Mira                                                        
Real-Time SW Engineering & Networking
Advanced Systems Engineering Division                                                               
CSEM - Centre Suisse d'Electronique et de Microtechnique 
Jaquet-Droz 1                                                                    Email:   matomira AT acm DOT org
CH-2007 Neuchatel                                                            Phone:    +41 (32) 720-5157
Switzerland                                                                       FAX:        +41 (32) 720-5720

http://www.csem.ch/         http://www.vrai.com/          http://ligwww.epfl.ch/matomira.html

Re: [ECOS] TCP/IP Stack for eCos

[Fred Fierling]

"Fernando D. Mato Mira" wrote:

> We are looking around right now because we want to have an embedded
> TCP/IP stack usable in a variety of contexts, particularly on raw processors/controllers/DSPs
> w/o an OS, and in cases where malloc is explicitly and formally forbidden.

A TCP stack that doesn't use malloc? Interesting. Do
you forbid malloc to avoid problems like memory
leaks, to guarantee response time, or why?

--
Fred Fierling                           Tel: +1 604 444-1717
Microplex Systems Ltd.                  Fax: +1 604 444-4239
8525 Commerce Court                 mailto:fff@microplex.com
Burnaby, BC   V5A 4N3               http://www.microplex.com/