[ECOS] TCP/IP Stack for eCos

[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

[ECOS] h800 porting looking for

[Paolo Torricelli]

i'm considering to port ecos on hitachi h/800
maybe anyway already working on it?
please feel free to email me
thanks
pt

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

[ECOS] Re: h800 porting looking for

[Bart Veer]

>>>>> "Paolo" == Paolo Torricelli <ptorric@tsc4.com> writes:

    Paolo> i'm considering to port ecos on hitachi h/800
    Paolo> maybe anyway already working on it?
    Paolo> please feel free to email me

A port to the h8/300 involves some complications, and I am not aware
of anybody currently working on one. A port by Cygnus is not currently
under consideration.

The problem is in the toolchain: as I understand it there is no g++
support for the h8/300, only gcc support; also ELF object format is
not yet supported for the h8, and some of the compiler facilities used
within eCos currently only work with ELF. Before starting any eCos
port to the h8 it would be necessary to sort out these issues.

Bart Veer // eCos net maintainer

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/

Re: [ECOS] Re: h800 porting looking for

[Paolo Torricelli]

>    Paolo> i'm considering to port ecos on hitachi h/800

>The problem is in the toolchain: as I understand it there is no g++
>support for the h8/300, only gcc support; also ELF object format is

At the present i'm using gcc by Cygnus as distributed in Hitachi cd-rom
I must understand why Ecos is maded with g++.
In my long years of computer activity i know (on my shink) that there is no
way to port anything if it isn't maded in simple (and very simple) C.
Anyway maybe i can consider to port gnu tools...maybe to adopt another OS.
This is not polemic, only a real topic sorry
ciao
pt

[ECOS] Re: h800 porting looking for

[Bart Veer]

>>>>> "Paolo" == Paolo Torricelli <ptorric@tsc4.com> writes:

    Paolo> i'm considering to port ecos on hitachi h/800
    >> The problem is in the toolchain: as I understand it there is no g++
    >> support for the h8/300, only gcc support; also ELF object format is

    Paolo> At the present i'm using gcc by Cygnus as distributed in
    Paolo> Hitachi cd-rom I must understand why Ecos is maded with
    Paolo> g++. In my long years of computer activity i know (on my
    Paolo> shink) that there is no way to port anything if it isn't
    Paolo> maded in simple (and very simple) C. Anyway maybe i can
    Paolo> consider to port gnu tools...maybe to adopt another OS.
    Paolo> This is not polemic, only a real topic sorry

It is a valid point, and the decision to use C++ for eCos rather than
ISO C was not an easy one. Another controversial decision we made
early on was to tie eCos to the GNU tools, making it very difficult to
use any other compiler technology. C++ is the more powerful language
of the two, even if some aspects of the language such as exception
handling usually cannot be used in an embedded system because of code
size issues.

In terms of availability, these days there are very few toolchains
where gcc is available but not g++ - the extra amount of work involved
is supposedly quite small, although I am not an expert on the
internals of the tools. The h8/300 is the exception rather than the
rule. If there is sufficient demand than either somebody will
contribute the necessary support or some major player (possibly
Hitachi, possibly a company that wants to use the h8 in a big project)
will pay for the work to be done.

Bart Veer // eCos net maintainer