Joel,
> > Recently I was in the same dilemma. Is the
OpenTCP project
> still active
> > ? I am about to integrate a TCP stack in my RTOS and I am
> choosing with
> > which one to go.
>
> Last release of OpenTCP: 2003-08-03
> The last post may sum it up on OpenTCP:
> http://sourceforge.net/forum/forum.php?thread_id31838&forum
> _id"4425
> Paul what where the big differences between lwIP and uIP?
lwIP has a sockets-like API, uIP doesn't. lwIP has many more
TCP/IP-related features than uIP does (windowing, for example) and will
potentially have a better throughput for applications that are streaming
data. uIP has a single segment in flight at any time hence falls foul
of delayed ACK implementations of TCP/IP (cf Windows at least). uIP
applications are harder to write than lwIP apps as uIP does not use
threads (but there is something called protothreads that you *can* use
to make life easier). lwIP is bigger in RAM and code size, uIP is small
in both. uIP runs a full web server on MSP430s in 8K of code with a
fully-compliant stack and less than 1K of memory (and that's with a big
packet buffer).
If you have space issues, uIP is the way to go. If you don't, then lwIP
is more the thing.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors
tcpip
Started by ●January 13, 2006
Reply by ●January 15, 20062006-01-15
Reply by ●January 15, 20062006-01-15
Hi Marko,
> Recently I was in the same dilemma. Is the OpenTCP project still active
> ? I am about to integrate a TCP stack in my RTOS and I am choosing with
> which one to go.
Last release of OpenTCP: 2003-08-03
The last post may sum it up on OpenTCP:
http://sourceforge.net/forum/forum.php?thread_id31838&forum_id"4425 Paul what where the big differences between lwIP and uIP? Joel
> Recently I was in the same dilemma. Is the OpenTCP project still active
> ? I am about to integrate a TCP stack in my RTOS and I am choosing with
> which one to go.
Last release of OpenTCP: 2003-08-03
The last post may sum it up on OpenTCP:
http://sourceforge.net/forum/forum.php?thread_id31838&forum_id"4425 Paul what where the big differences between lwIP and uIP? Joel
Reply by ●January 15, 20062006-01-15
> > Paul what where the big differences between lwIP and uIP?
>
> lwIP has a sockets-like API, uIP doesn't. lwIP has many more
> TCP/IP-related features than uIP does (windowing, for example) and will
> potentially have a better throughput for applications that are streaming
> data. uIP has a single segment in flight at any time hence falls foul
> of delayed ACK implementations of TCP/IP (cf Windows at least). uIP
> applications are harder to write than lwIP apps as uIP does not use
> threads (but there is something called protothreads that you *can* use
> to make life easier). lwIP is bigger in RAM and code size, uIP is small
> in both. uIP runs a full web server on MSP430s in 8K of code with a
> fully-compliant stack and less than 1K of memory (and that's with a big
> packet buffer).
>
> If you have space issues, uIP is the way to go. If you don't, then lwIP
> is more the thing.
Paul thanks for the excellent summation. Can anyone with Ethernet Nut/Net experience comment? Joel
>
> lwIP has a sockets-like API, uIP doesn't. lwIP has many more
> TCP/IP-related features than uIP does (windowing, for example) and will
> potentially have a better throughput for applications that are streaming
> data. uIP has a single segment in flight at any time hence falls foul
> of delayed ACK implementations of TCP/IP (cf Windows at least). uIP
> applications are harder to write than lwIP apps as uIP does not use
> threads (but there is something called protothreads that you *can* use
> to make life easier). lwIP is bigger in RAM and code size, uIP is small
> in both. uIP runs a full web server on MSP430s in 8K of code with a
> fully-compliant stack and less than 1K of memory (and that's with a big
> packet buffer).
>
> If you have space issues, uIP is the way to go. If you don't, then lwIP
> is more the thing.
Paul thanks for the excellent summation. Can anyone with Ethernet Nut/Net experience comment? Joel
Reply by ●January 16, 20062006-01-16
>>
>>If you have space issues, uIP is the way to go. If you don't, then lwIP
>>is more the thing.
>
> Can anyone with Ethernet Nut/Net experience comment?
<< Apologies in advance for the infomercial, I have no commercial connection,
just very pleased with the results >>
I can not comment on the internal IP stack structure of EtherNut beyond saying
the following:
- EtherNut & it's co-operative RTOS are effective on small footprint embedded
systems, it started on an 8 bit AVR. It is there & it works with many years of
history in a broad range of commercial apps.
- The stack uses the single copy of the packet & doesn't copy between layers.
This is explained in the document "Ethernut Software Manual" on the documents
page, the link for which is given below.
- It is actively being developed and supported by it's author and user-base.
~ 10 postings per day on forum. The big kids don't poke fun at me when I ask
dumb noob questions.
- It is functionally documented - http://www.ethernut.de/en/documents/index.html
- Reference hardware is available from the author at www.egnite.de
- It has a configuration system which allows even GNUuoobs such as me to be able
to readily build it and use it with either GCC or some other commercial compilers.
- In short I can easily run the comprehensive range of examples and make the
leds flash without too much hair loss. This alone may allow me to get to a point
where I <can> make intelligent comment about stack internals at a later date.
- The author hasn't done what a number of other open source projects have done &
used contributors as beta testers before sealing off further open source
development and going closed commercial... So far ;-)
- There is an ARM7 version but it is currently targeted at an older Atmel
AT91R40008 ARM device which greatly pre-dates the SAM7 & LPC2xxx
- Another contributor is currently doing an LPC2xxx port but as yet the source
has not been made available. http://www.usbdip.de/en/ethernut2294/index.html It
is built with the crossworks compiler
- Contributors appear to be waiting to see how the cards fall in the latest
Philips / Atmel ARM based product releases before advancing the ARM port.
Shouldn't be long however.
- The stack seems to have a consistent, functional community that is generous
with it's contributions and support. People come and go & have done so for many
years leaving extra bits on the stack. The stack just slowly gets better. That
is important if you are going to spend the time getting up to speed with it.
In my particular case with the XNut hardware product which also uses the
Ethernut stack ( similarly well supported by it's creator www.focus-sw.com ) we
got from concept to invoiceable application in no time flat & for me that is
what keeps the customer happy & the family fed. I eagerly await the new ARM
based units.
Cheers
Don
>>If you have space issues, uIP is the way to go. If you don't, then lwIP
>>is more the thing.
>
> Can anyone with Ethernet Nut/Net experience comment?
<< Apologies in advance for the infomercial, I have no commercial connection,
just very pleased with the results >>
I can not comment on the internal IP stack structure of EtherNut beyond saying
the following:
- EtherNut & it's co-operative RTOS are effective on small footprint embedded
systems, it started on an 8 bit AVR. It is there & it works with many years of
history in a broad range of commercial apps.
- The stack uses the single copy of the packet & doesn't copy between layers.
This is explained in the document "Ethernut Software Manual" on the documents
page, the link for which is given below.
- It is actively being developed and supported by it's author and user-base.
~ 10 postings per day on forum. The big kids don't poke fun at me when I ask
dumb noob questions.
- It is functionally documented - http://www.ethernut.de/en/documents/index.html
- Reference hardware is available from the author at www.egnite.de
- It has a configuration system which allows even GNUuoobs such as me to be able
to readily build it and use it with either GCC or some other commercial compilers.
- In short I can easily run the comprehensive range of examples and make the
leds flash without too much hair loss. This alone may allow me to get to a point
where I <can> make intelligent comment about stack internals at a later date.
- The author hasn't done what a number of other open source projects have done &
used contributors as beta testers before sealing off further open source
development and going closed commercial... So far ;-)
- There is an ARM7 version but it is currently targeted at an older Atmel
AT91R40008 ARM device which greatly pre-dates the SAM7 & LPC2xxx
- Another contributor is currently doing an LPC2xxx port but as yet the source
has not been made available. http://www.usbdip.de/en/ethernut2294/index.html It
is built with the crossworks compiler
- Contributors appear to be waiting to see how the cards fall in the latest
Philips / Atmel ARM based product releases before advancing the ARM port.
Shouldn't be long however.
- The stack seems to have a consistent, functional community that is generous
with it's contributions and support. People come and go & have done so for many
years leaving extra bits on the stack. The stack just slowly gets better. That
is important if you are going to spend the time getting up to speed with it.
In my particular case with the XNut hardware product which also uses the
Ethernut stack ( similarly well supported by it's creator www.focus-sw.com ) we
got from concept to invoiceable application in no time flat & for me that is
what keeps the customer happy & the family fed. I eagerly await the new ARM
based units.
Cheers
Don
Reply by ●January 16, 20062006-01-16
> > Paul what where the big differences between lwIP and uIP?
>
> lwIP has a sockets-like API, uIP doesn't. lwIP has many more
> TCP/IP-related features than uIP does (windowing, for example) and will
> potentially have a better throughput for applications that are streaming
> data. uIP has a single segment in flight at any time hence falls foul
> of delayed ACK implementations of TCP/IP (cf Windows at least). uIP
> applications are harder to write than lwIP apps as uIP does not use
> threads (but there is something called protothreads that you *can* use
> to make life easier). lwIP is bigger in RAM and code size, uIP is small
> in both. uIP runs a full web server on MSP430s in 8K of code with a
> fully-compliant stack and less than 1K of memory (and that's with a big
> packet buffer).
>
> If you have space issues, uIP is the way to go. If you don't, then lwIP
> is more the thing.
Just to demonstrate Pauls points...
uIP is a really nice, small and easy to understand system. It's major
disadvantage is that only one packet can be outstanding at any one time.
This is less of a problem if you have control over both ends of the
communication, but can make streaming data to (for example) Windoze rather
slow.
The following page generates a lot of dynamic data and sends it as one
packet (this uses a non standard port number so if you are on a company
network or behind certain firewalls it will not load):
http://82.32.114.142:47822/cgi/rtos
It should load quickly. On the other hand the following page generates
dynamic data one line at a time, and sends each line individually. You
should find this then loads much more slowly as Windoze delays acknowledging
each packet (same firewall restrictions apply).
http://82.32.114.142:47822/cgi/tcp
Therefore, uIP can work with very small buffers but this then restricts the
throughput you can achieve. Like everything it is a trade off. lwIP is a much fuller implementation that removes this restriction at the
expense of more CPU cycles and more RAM. Also the driver required for the
NIC is more complex. If you look at the SAM7X emac drivers for the
respective FreeRTOS uIP and lwIP demos you will see the former is much
simpler due to the simple buffer management in uIP.
Regards,
Richard.
http://www.FreeRTOS.org
>
> lwIP has a sockets-like API, uIP doesn't. lwIP has many more
> TCP/IP-related features than uIP does (windowing, for example) and will
> potentially have a better throughput for applications that are streaming
> data. uIP has a single segment in flight at any time hence falls foul
> of delayed ACK implementations of TCP/IP (cf Windows at least). uIP
> applications are harder to write than lwIP apps as uIP does not use
> threads (but there is something called protothreads that you *can* use
> to make life easier). lwIP is bigger in RAM and code size, uIP is small
> in both. uIP runs a full web server on MSP430s in 8K of code with a
> fully-compliant stack and less than 1K of memory (and that's with a big
> packet buffer).
>
> If you have space issues, uIP is the way to go. If you don't, then lwIP
> is more the thing.
Just to demonstrate Pauls points...
uIP is a really nice, small and easy to understand system. It's major
disadvantage is that only one packet can be outstanding at any one time.
This is less of a problem if you have control over both ends of the
communication, but can make streaming data to (for example) Windoze rather
slow.
The following page generates a lot of dynamic data and sends it as one
packet (this uses a non standard port number so if you are on a company
network or behind certain firewalls it will not load):
http://82.32.114.142:47822/cgi/rtos
It should load quickly. On the other hand the following page generates
dynamic data one line at a time, and sends each line individually. You
should find this then loads much more slowly as Windoze delays acknowledging
each packet (same firewall restrictions apply).
http://82.32.114.142:47822/cgi/tcp
Therefore, uIP can work with very small buffers but this then restricts the
throughput you can achieve. Like everything it is a trade off. lwIP is a much fuller implementation that removes this restriction at the
expense of more CPU cycles and more RAM. Also the driver required for the
NIC is more complex. If you look at the SAM7X emac drivers for the
respective FreeRTOS uIP and lwIP demos you will see the former is much
simpler due to the simple buffer management in uIP.
Regards,
Richard.
http://www.FreeRTOS.org
Reply by ●January 16, 20062006-01-16
Hi Richard,
> uIP is a really nice, small and easy to understand system. It's major
> disadvantage is that only one packet can be outstanding at any one time.
> This is less of a problem if you have control over both ends of the
> communication, but can make streaming data to (for example) Windoze rather
> slow.
Any plans to have a live lwIP demo? This would be a nice A-B test to your
live uIP demo. Joel
> uIP is a really nice, small and easy to understand system. It's major
> disadvantage is that only one packet can be outstanding at any one time.
> This is less of a problem if you have control over both ends of the
> communication, but can make streaming data to (for example) Windoze rather
> slow.
Any plans to have a live lwIP demo? This would be a nice A-B test to your
live uIP demo. Joel
Reply by ●January 16, 20062006-01-16
> Any plans to have a live lwIP demo? This would be a nice A-B test to
your
> live uIP demo.
The lwIP demo uses the same hardware as the uIP demo so they cannot both be
live at the same time. The demo is also a bit basic with just a single page
of dynamic text being returned. As it was not live I didn't do anything
fancy (the uIP demo uses frames and contains graphics if you go to the root
rather than the links I gave).
There is a live LPC2124 / Crystal LAN CS8900 demo. This is basically Pauls
code running (practically unmodified) as a task under FreeRTOS.org. Due to
hardware limitations it bit bangs the NIC and does not use interrupts. See
http://www.freertos.org/embeddedtcp.html for the various links.
Regards,
Richard.
http://www.FreeRTOS.org
> live uIP demo.
The lwIP demo uses the same hardware as the uIP demo so they cannot both be
live at the same time. The demo is also a bit basic with just a single page
of dynamic text being returned. As it was not live I didn't do anything
fancy (the uIP demo uses frames and contains graphics if you go to the root
rather than the links I gave).
There is a live LPC2124 / Crystal LAN CS8900 demo. This is basically Pauls
code running (practically unmodified) as a task under FreeRTOS.org. Due to
hardware limitations it bit bangs the NIC and does not use interrupts. See
http://www.freertos.org/embeddedtcp.html for the various links.
Regards,
Richard.
http://www.FreeRTOS.org
Reply by ●January 16, 20062006-01-16
> The lwIP demo uses the same hardware as the uIP demo so they cannot
both
> be
> live at the same time. The demo is also a bit basic with just a single
> page
> of dynamic text being returned. As it was not live I didn't do anything
> fancy (the uIP demo uses frames and contains graphics if you go to the
> root
> rather than the links I gave).
Perhaps you might periodically rotate between the two? > There is a live LPC2124 / Crystal LAN CS8900 demo. This is basically
> Pauls
> code running (practically unmodified) as a task under FreeRTOS.org. Due
> to
> hardware limitations it bit bangs the NIC and does not use interrupts.
> See
> http://www.freertos.org/embeddedtcp.html for the various links.
This one does not load in Firefox, IE is fine. "Alert - The document
contains no data". Joel
> be
> live at the same time. The demo is also a bit basic with just a single
> page
> of dynamic text being returned. As it was not live I didn't do anything
> fancy (the uIP demo uses frames and contains graphics if you go to the
> root
> rather than the links I gave).
Perhaps you might periodically rotate between the two? > There is a live LPC2124 / Crystal LAN CS8900 demo. This is basically
> Pauls
> code running (practically unmodified) as a task under FreeRTOS.org. Due
> to
> hardware limitations it bit bangs the NIC and does not use interrupts.
> See
> http://www.freertos.org/embeddedtcp.html for the various links.
This one does not load in Firefox, IE is fine. "Alert - The document
contains no data". Joel
Reply by ●January 16, 20062006-01-16
Reply by ●January 16, 20062006-01-16
> > See
> > http://www.freertos.org/embeddedtcp.html for the various links. > This one does not load in Firefox, IE is fine. "Alert - The document
> contains no data".
Err, that's not good. Just looked at the file and it doesn't have the
<html></html> parts. I think this was doxygen created originally. Need to
go through and check all the pages for this, but am surprised Firefox
doesn't make a stab at displaying it.
Regards,
Richard.
http://www.FreeRTOS.org
> > http://www.freertos.org/embeddedtcp.html for the various links. > This one does not load in Firefox, IE is fine. "Alert - The document
> contains no data".
Err, that's not good. Just looked at the file and it doesn't have the
<html></html> parts. I think this was doxygen created originally. Need to
go through and check all the pages for this, but am surprised Firefox
doesn't make a stab at displaying it.
Regards,
Richard.
http://www.FreeRTOS.org
