Lpc2000

Hello,


I'd ported OpenTCP to lpc2292 with rtl8019. I'll add cs8900 and enj28j60 drivers. (All of them working with ported avrlib netstack with lpc2292, so it will be trivial.)

I add a very basic and simple device structure, becouse i would like to use slip too, and then add ppp, etc...

Somebody interested to help developing it? ;)



Andrew

--- In lpc2000@yahoogroups.com, Szemzõ András <a.szemzo@k...> wrote:

Hello,
   Where I can find more information about OpenTCP ?
> Hello,
> 
> 
> I'd ported OpenTCP to lpc2292 with rtl8019. I'll add cs8900 and
enj28j60 drivers. (All of them working with ported avrlib netstack
with lpc2292, so it will be trivial.)
> 
> I add a very basic and simple device structure, becouse i would like
to use slip too, and then add ppp, etc...

> 
> Somebody interested to help developing it? ;)
> 
> 
> 
> Andrew
>

> Hello,
>    Where I can find more information about OpenTCP ?

http://sourceforge.net/project/showfiles.php?group_id=66182

Andrew,

Yes, I am interested.
I've got different boards to do this on, but no lpc2292.
I am currently interfacing the enc28j60 to my board. For my project I do
not need a full TCP stack, I was just asked to show that the enc28j60 is a
workable ethernet solution for a few other projects.

So all I _must_ do is to show a working MAC with the enc, but a full
tcp/ip solution may be so much easier to demo ...

I have the enc28j60 connected to SPI0 and use GCC.
Just drop me an email if you're interested - I can add the 28j60 driver.
I have also en Embedded Artists 2138 board with a DM7000 (10/100 Mb
Ethernet) and can maybe add that driver also.

Regards,

      Rob

> Hello,
>
> I'd ported OpenTCP to lpc2292 with rtl8019. I'll add cs8900 and enj28j60
> drivers. (All of them working with ported avrlib netstack with lpc2292, so
> it will be trivial.)
>
> I add a very basic and simple device structure, becouse i would like to
> use slip too, and then add ppp, etc...
>
> Somebody interested to help developing it? ;)
>
>
> Andrew

Hi Andrew,

> I'd ported OpenTCP to lpc2292 with rtl8019. I'll add cs8900 and enj28j60
> drivers. (All of them working with ported avrlib netstack with lpc2292, so
> it will be trivial.)
>
> I add a very basic and simple device structure, becouse i would like to
> use slip too, and then add ppp, etc...
>
> Somebody interested to help developing it? ;)

I may be interested in adding ppp/slip.  The OpenTCP code has much better
documentation than lwip, or uip.

GCC?


Joel

Joel Winarske wrote:
> Hi Andrew,
> 
> 
>>I'd ported OpenTCP to lpc2292 with rtl8019. I'll add cs8900 and enj28j60
>>drivers. (All of them working with ported avrlib netstack with lpc2292, so
>>it will be trivial.)
>>
>>I add a very basic and simple device structure, becouse i would like to
>>use slip too, and then add ppp, etc...
>>
>>Somebody interested to help developing it? ;)
> 
> 
> I may be interested in adding ppp/slip.  The OpenTCP code has much better
> documentation than lwip, or uip.
> 
> GCC?
> 
> 
> Joel
> 

Out of curiosity, how does this compare in performance or functionality to 
Ethernut on ARM? There is also an LPC port for this under way.

Cheers

Don

> Out of curiosity, how does this compare in performance or functionality to
> Ethernut on ARM? There is also an LPC port for this under way.

Here's a brief overview of free stacks, in alphabetical order:

Nut/Net (Ethernut) - IPV4, TCP, UDP, ICMP, PPP (minimal) - PAP, stack
documentation?  fragmented packet support?

lwIP 1.1.0 - IPV4, IPV6, TCP, UDP, DHCP, ICMP, PPP - PAP, CHAP, VJ, minimal
documentation, fragmented packet support.

OpenTCP - IPV4, TCP, UDP, DHCP, ICMP, DNS, BOOTP, TFTP, SMTP, POP3, HTTP,
good documentation.  Fragmented packet support?

uIP - IPV4, TCP, UDP, DHCP, SMTP, POP3, HTTP, TELNET, FTP, VNC, IRC, PPP -
PAP, zero documentation, no fragmented packet support.  See Contiki project
for recent code base.


On the ones that support POP3 and SMTP, it appears clear text authentication
is only implemented.  Most modern ISPs require more than this.

The best performing would be dependent on a number of variables - in no
particular order:

1.  I/O bandwidth to EMAC.  This could be a combination of EMAC receive
buffer size, DMA between EMAC and RAM, bit banged port, polled driver, or
interrupt driven I/O.
2.  EMAC hardware filtering - prevents MCU from handling unwanted traffic
3.  Available MCU RAM.
4.  Protocol stack - buffer management.  Zero copy?  Does stack offer
predefined memory pool or is malloc() required?
5.  Protocol stack - CRC implementation.  Some silicon offers hardware CRC
to increase throughput.  Example - Maxim/Dallas DS80C4xx series.

etc. etc.


These are not specific to ARM, but Ethernet in general.  From here you weigh
your design requirements, the MCU features, and the protocol stack.  The
integration of the EMAC can be the biggest performance variable.

 
HTH,
Joel

Joel, 

> uIP - IPV4, TCP, UDP, DHCP, SMTP, POP3, HTTP, TELNET, FTP, 
> VNC, IRC, PPP -
> PAP, zero documentation

No, Documentation is extensive:

http://www.sics.se/~adam/uip/uip-0.9-refman/

> no fragmented packet support.  

Wrong.  Set UIP_REASSEMBLY.

http://www.sics.se/~adam/uip/uip-0.9-refman/a00088.html#a1

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors#

Hi,

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.

marko
http://usmartx.sourceforge.net

Joel Winarske wrote:

>>Out of curiosity, how does this compare in performance or functionality to
>>Ethernut on ARM? There is also an LPC port for this under way.
>>    
>>
>
>Here's a brief overview of free stacks, in alphabetical order:
>
>Nut/Net (Ethernut) - IPV4, TCP, UDP, ICMP, PPP (minimal) - PAP, stack
>documentation?  fragmented packet support?
>
>lwIP 1.1.0 - IPV4, IPV6, TCP, UDP, DHCP, ICMP, PPP - PAP, CHAP, VJ, minimal
>documentation, fragmented packet support.
>
>OpenTCP - IPV4, TCP, UDP, DHCP, ICMP, DNS, BOOTP, TFTP, SMTP, POP3, HTTP,
>good documentation.  Fragmented packet support?
>
>uIP - IPV4, TCP, UDP, DHCP, SMTP, POP3, HTTP, TELNET, FTP, VNC, IRC, PPP -
>PAP, zero documentation, no fragmented packet support.  See Contiki project
>for recent code base.
>
>
>On the ones that support POP3 and SMTP, it appears clear text authentication
>is only implemented.  Most modern ISPs require more than this.
>
>The best performing would be dependent on a number of variables - in no
>particular order:
>
>1.  I/O bandwidth to EMAC.  This could be a combination of EMAC receive
>buffer size, DMA between EMAC and RAM, bit banged port, polled driver, or
>interrupt driven I/O.
>2.  EMAC hardware filtering - prevents MCU from handling unwanted traffic
>3.  Available MCU RAM.
>4.  Protocol stack - buffer management.  Zero copy?  Does stack offer
>predefined memory pool or is malloc() required?
>5.  Protocol stack - CRC implementation.  Some silicon offers hardware CRC
>to increase throughput.  Example - Maxim/Dallas DS80C4xx series.
>
>etc. etc.
>
>
>These are not specific to ARM, but Ethernet in general.  From here you weigh
>your design requirements, the MCU features, and the protocol stack.  The
>integration of the EMAC can be the biggest performance variable.
>
> 
>HTH,
>Joel
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>
>  
>



[Non-text portions of this message have been removed]

> > uIP - IPV4, TCP, UDP, DHCP, SMTP, POP3, HTTP, TELNET, FTP,
> > VNC, IRC, PPP -
> > PAP, zero documentation
> 
> No, Documentation is extensive:
> 
> http://www.sics.se/~adam/uip/uip-0.9-refman/
> 
> > no fragmented packet support.
> 
> Wrong.  Set UIP_REASSEMBLY.
> 
> http://www.sics.se/~adam/uip/uip-0.9-refman/a00088.html#a1


Ah yes, my bad.  Thank you for pointing these out Paul.

Corrections and comments are always welcome.


Joel

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_id=1031838&forum
> _id=224425
> 
> 
> 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

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_id=1031838&forum_id=224425


Paul what where the big differences between lwIP and uIP?


Joel

> > 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

>>
>>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

> > 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

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

> 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

> 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

Hi,

I'd uploaded  OpenTCP-lpc.zip to the files section. 


Andrew

> > 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

hi, 
 
 
and what about that? 
 
http://sourceforge.net/projects/freescaleotcp/

Andrew
________________________________

From: lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] On Behalf Of
Joel Winarske
Sent: Sunday, January 15, 2006 11:08 PM
To: lpc2000@yahoogroups.com
Subject: RE: [lpc2000] tcpip


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_id=1031838&forum_id=224425


Paul what where the big differences between lwIP and uIP?


Joel





SPONSORED LINKS 
Microprocessor
<http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Mic
rocontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=t
sVC-J9hJ5qyXg0WPR0l6g>  	Microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=M
icrocontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig
=DvJVNqC_pqRTm8Xq01nxwg>  	Pic microcontrollers
<http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&
w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&
.sig=TpkoX4KofDJ7c6LyBvUqVQ>  	
8051 microprocessor
<http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w
2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.
sig=1Ipf1Fjfbd_HVIlekkDP-A>  	

________________________________

YAHOO! GROUPS LINKS 


	*	 Visit your group "lpc2000
<http://groups.yahoo.com/group/lpc2000> " on the web.
	  
*	 To unsubscribe from this group, send an email to:
	 lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
	  
*	 Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 


________________________________

Hi Andrew,

> and what about that?
> 
> http://sourceforge.net/projects/freescaleotcp/

It's fairly recent.  August 31, 2005.

Only ten of the OpenTCP-1.0.4.src files are modified.  Most changes are
compiler related.  http_server.c seems to have the largest delta.  On others
the only changes are removal of the license header, and include directories.

I would start with this version over OpenTCP-1.0.4.src, as there are some
useful looking changes.


Joel

Here I use firefox and it works fine.



Joel Winarske wrote:
> > 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
>
>
>
>
> SPONSORED LINKS
> Microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g> 
> 	Microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg> 
> 	Pic microcontrollers 
> <http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ> 
>
> 8051 microprocessor 
> <http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A> 
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

It works fine on the AT91SAM7X demo, and not the Crystal demo.  I had the
same results some time back.  If I browse the Crystal demo in IE, it's fine.

I'm running the default install on Firefox, no tweaks.

Here too.
Win XP Pro.
Firefox 1.5

http://82.32.114.142:47821/
http://82.32.114.142:47820/
http://82.32.114.142:47822/cgi/tcp
http://82.32.114.142:47822/cgi/rtos

all of them works fine.




Joel Winarske wrote:
> It works fine on the AT91SAM7X demo, and not the Crystal demo.  I had the
> same results some time back.  If I browse the Crystal demo in IE, it's 
> fine.
>
> I'm running the default install on Firefox, no tweaks.
>
>
>
> ------------------------------------------------------------------------
> YAHOO! GROUPS LINKS
>
>     *  Visit your group "lpc2000
>       <http://groups.yahoo.com/group/lpc2000>" on the web.
>        
>     *  To unsubscribe from this group, send an email to:
>        lpc2000-unsubscribe@yahoogroups.com
>       <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>
>        
>     *  Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>       Service <http://docs.yahoo.com/info/terms/>.
>
>
> ------------------------------------------------------------------------
>



[Non-text portions of this message have been removed]

> Here too.
> Win XP Pro.
> Firefox 1.5
> 
> http://82.32.114.142:47821/
> http://82.32.114.142:47820/
> http://82.32.114.142:47822/cgi/tcp
> http://82.32.114.142:47822/cgi/rtos
> 
> all of them works fine.


Hmm.    First round the second listed was giving me "The document contains
no data."  After multiple tries through the list then the second worked and
the first start complaining.  Are all of these running uIP I wonder?

XP
Firefox 1.0.7

> > Here too.
> > Win XP Pro.
> > Firefox 1.5
> >
> > http://82.32.114.142:47821/
> > http://82.32.114.142:47820/
> > http://82.32.114.142:47822/cgi/tcp
> > http://82.32.114.142:47822/cgi/rtos
> >
> > all of them works fine.
>
>
> Hmm.    First round the second listed was giving me "The document contains
> no data."  After multiple tries through the list then the second worked
and
> the first start complaining.  Are all of these running uIP I wonder?
>
> XP
> Firefox 1.0.7


The 47820 port is using a WizNET I2C interface.

The 47821 is Pauls uIP demo bit banging a Crystal LAN running as a task
under FreeRTOS (LPC).

The 47822 is uIP running with interrupts and DMA on a SAM7X.

The number of simultaneous connections is limited (#define in the code).  If
you look at a page that sends lots of small packets then each takes a
connection.  I imagine that posting the addresses here is generating several
simulations hits, so maybe its just running out of connections hence the
intermittence.

All works fine for me, but the boards are only a few feet away.  Also I'm
using IE rather than Firefox.

Regards,
Richard.

http://www.FreeRTOS.org

IE loads them fine on my machine.  On the ones in question, in IE there is a
delayed load between the header and body.

It's a curious difference between Firefox and IE.

A tracert of 82.32.114.142 results in over 30 network hops.  This may have a
bearing on things.  Are you in the UK?  I'm in California. 


Joel

> > > Here too.
> > > Win XP Pro.
> > > Firefox 1.5
> > >
> > > http://82.32.114.142:47821/
> > > http://82.32.114.142:47820/
> > > http://82.32.114.142:47822/cgi/tcp
> > > http://82.32.114.142:47822/cgi/rtos
> > >
> > > all of them works fine.
> >
> >
> > Hmm.    First round the second listed was giving me "The document
> contains
> > no data."  After multiple tries through the list then the second worked
> and
> > the first start complaining.  Are all of these running uIP I wonder?
> >
> > XP
> > Firefox 1.0.7
> 
> 
> The 47820 port is using a WizNET I2C interface.
> 
> The 47821 is Pauls uIP demo bit banging a Crystal LAN running as a task
> under FreeRTOS (LPC).
> 
> The 47822 is uIP running with interrupts and DMA on a SAM7X.
> 
> The number of simultaneous connections is limited (#define in the code).
> If
> you look at a page that sends lots of small packets then each takes a
> connection.  I imagine that posting the addresses here is generating
> several
> simulations hits, so maybe its just running out of connections hence the
> intermittence.
> 
> All works fine for me, but the boards are only a few feet away.  Also I'm
> using IE rather than Firefox.

Just a "me too", they all work fine for me (WinXP IE6) but they are 
sloooowwww...

At 04:23 PM 1/16/2006, you wrote:

> > > Here too.
> > > Win XP Pro.
> > > Firefox 1.5
> > >
> > > <http://82.32.114.142:47821/>http://82.32.114.142:47821/
> > > http://82.32.114.142:47820/
> > > <http://82.32.114.142:47822/cgi/tcp>http://82.32.114.142:47822/cgi/tcp
> > > http://82.32.114.142:47822/cgi/rtos
> > >
> > > all of them works fine.
> >
> >
> > Hmm.    First round the second listed was giving me "The document contains
> > no data."  After multiple tries through the list then the second worked
>and
> > the first start complaining.  Are all of these running uIP I wonder?
> >
> > XP
> > Firefox 1.0.7
>
>
>The 47820 port is using a WizNET I2C interface.
>
>The 47821 is Pauls uIP demo bit banging a Crystal LAN running as a task
>under FreeRTOS (LPC).
>
>The 47822 is uIP running with interrupts and DMA on a SAM7X.
>
>The number of simultaneous connections is limited (#define in the code).  If
>you look at a page that sends lots of small packets then each takes a
>connection.  I imagine that posting the addresses here is generating several
>simulations hits, so maybe its just running out of connections hence the
>intermittence.
>
>All works fine for me, but the boards are only a few feet away.  Also I'm
>using IE rather than Firefox.
>
>Regards,
>Richard.
>
><http://www.FreeRTOS.org>http://www.FreeRTOS.org
>
>
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=tsVC-J9hJ5qyXg0WPR0l6g>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=DvJVNqC_pqRTm8Xq01nxwg>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Pic+microcontrollers&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=TpkoX4KofDJ7c6LyBvUqVQ>Pic 
>microcontrollers
><http://groups.yahoo.com/gads?t=ms&k=8051+microprocessor&w1=Microprocessor&w2=Microcontrollers&w3=Pic+microcontrollers&w4=8051+microprocessor&c=4&s=93&.sig=1Ipf1Fjfbd_HVIlekkDP-A>8051 
>microprocessor
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------

> IE loads them fine on my machine.  On the ones in question, in IE there is
a
> delayed load between the header and body.
>
> It's a curious difference between Firefox and IE.
>
> A tracert of 82.32.114.142 results in over 30 network hops.  This may have
a
> bearing on things.  Are you in the UK?  I'm in California.


Yep - UK - just a few thousand miles away.

Richard.

http://www.FreeRTOS.org

> Just a "me too", they all work fine for me (WinXP IE6) but they are
> sloooowwww...
>

Even this one? http://82.32.114.142:47822/cgi/rtos

My contribution to this thread started by saying that uIP could be sped up
by sending dynamic data as single buffer rather than lots of small ones -
using this link as an example compared to the other links.  The standard uIP
demo from Adam Dunkels site sends each dynamically generated item
separately - hence lots of delayed acks and a slow connection to Windoze.

From here I find this page loads quickly, but I'm not 30hops away.

Regards,
Richard.

http://www.FreeRTOS.org

> Even this one? http://82.32.114.142:47822/cgi/rtos
> 

I've never had a problem with this one.  It's quite reasonable even 30+ hops
away.


Joel

OK, just another "metoo".

lynx 82.32.114.142:47821 works just fine:

Task          State  Priority  Stack    #
************************************************

uIP             R       3       64      0
PolSEM1         R       0       84      8
PolSEM2         R       0       84      9
IDLE            R       0       99      13
SUSP_RX         R       0       88      7
C_CTRL          R       0       90      5
CNT_INC         R       0       91      3
QConsNB         B       2       99      1
QProdNB         B       2       92      2
BlkSEM1         B       1       84      10
BlkSEM2         B       1       84      11
Check           B       4       100     12
SUSP_TX         B       0       94      6
LIM_INC         S       1       95      4

it shows two frames.

But traceroute gets lost somewhere... over 30 hops (from Slovenia)...

-bash-2.05b$ traceroute -p47821 82.32.114.142 0x40
traceroute to 82.32.114.142 (82.32.114.142), 64 hops max, 64 byte packets
 1  BSN-access.dsl.siol.net (213.250.19.90)  38.685 ms  24.747 ms  13.518 ms
 2  213.250.19.169 (213.250.19.169)  13.265 ms  12.290 ms  13.234 ms
 3  213.250.18.97 (213.250.18.97)  14.052 ms * *
 4  kklag1-176-57.net.uta.at (212.152.176.57)  52.157 ms  21.890 ms  
47.014 ms
 5  C76wmode1-tengigE-4-2.net.uta.at (212.152.192.174)  22.154 ms  
36.087 ms  58.871 ms
 6  vie3-core.gigabiteth1-0.swip.net (130.244.205.57)  23.852 ms  45.033 
ms  24.089 ms
 7  fra2-core.pos12-0.swip.net (130.244.193.154)  68.209 ms  73.552 ms  
69.963 ms
 8  weis-core-1.pos0-0.swip.net (130.244.194.181)  145.105 ms  109.349 
ms  92.789 ms
 9  some.frankfurt.router.Level3.net (130.244.200.86)  39.166 ms  67.372 
ms  60.312 ms
10  ae-0-53.bbr1.Frankfurt1.Level3.net (195.122.136.65)  38.923 ms  
70.912 ms ae-0-55.bbr1.Frankfurt1.Level3.net (195.122.136.97)  57.105 ms
11  as-0-0.bbr1.London1.Level3.net (4.68.128.109)  120.925 ms  93.313 
ms  75.871 ms
12  ae-0-17.gar1.London1.Level3.net (212.187.131.169)  54.945 ms 
ae-0-15.gar1.London1.Level3.net (212.187.131.137)  56.411 ms 
ae-0-17.gar1.London1.Level3.net (212.187.131.169)  91.576 ms
13  195.50.91.2 (195.50.91.2)  55.339 ms 195.50.91.6 (195.50.91.6)  
55.799 ms  70.178 ms
14  azt-tele1-pos.telewest.net (194.117.136.1)  103.056 ms  73.372 ms  
66.472 ms
15  195.188.230.5 (195.188.230.5)  59.610 ms  138.936 ms  223.461 ms
16  195.188.230.58 (195.188.230.58)  86.663 ms  105.322 ms  65.731 ms
17  195.188.230.188 (195.188.230.188)  59.584 ms  93.585 ms  97.788 ms
18  * * *


Sorry for garbage :)




FreeRTOS Info wrote:

> > IE loads them fine on my machine.  On the ones in question, in IE 
> there is
> a
> > delayed load between the header and body.
> >
> > It's a curious difference between Firefox and IE.
> >
> > A tracert of 82.32.114.142 results in over 30 network hops.  This 
> may have
> a
> > bearing on things.  Are you in the UK?  I'm in California.
>
>
> Yep - UK - just a few thousand miles away.
>
> Richard.
>
> http://www.FreeRTOS.org
>

Sorry, my bad, the last one loads fast, the other 3 are pretty slow.

-- Sean

At 04:58 PM 1/16/2006, you wrote:

> > Just a "me too", they all work fine for me (WinXP IE6) but they are
> > sloooowwww...
> >
>
>Even this one? 
><http://82.32.114.142:47822/cgi/rtos>http://82.32.114.142:47822/cgi/rtos
>
>My contribution to this thread started by saying that uIP could be sped up
>by sending dynamic data as single buffer rather than lots of small ones -
>using this link as an example compared to the other links.  The standard uIP
>demo from Adam Dunkels site sends each dynamically generated item
>separately - hence lots of delayed acks and a slow connection to Windoze.
>
> From here I find this page loads quickly, but I'm not 30hops away.
>
>Regards,
>Richard.
>
><http://www.FreeRTOS.org>http://www.FreeRTOS.org

Hi All

Just to make things a little more complicated. We also offer a 
TCP/IP stack with integrated operating system, a simulator and 
project support for GNU and IAR Embedded work bench. It is available 
freely to educational establishments and also supported by Email.

Since it is also used for commercial projects, it is presently 
restricted to the above mentioned distribution. It is also only 
available for Freescale MC9S12NE64 and ATMEL AT91SAM7X projects (as 
soon as the new LPC is available it will also get a project)

The operating system and stack include the standard things plus FTP 
with FLASH or serial SPI EEPROM file system, Telnet, dynamic HTTP 
and fits (when all activated) into about 15k..20k of FLASH and need 
about 3k of RAM (depending on the resource defined). 

There are a few demos on line at www.mjbc.ch (login always using 
user name "anon" and password "anon"). These use the NE64 as basis 
since the ATMEL is still only avilable in limited quantities and so 
there are not enough here for permanent demos. The NE64 devices have 
limited resources and so do not use transmission windowing.

Apart from the published demos there is also a development device in 
a DMZ at 212.254.22.36 which can be (anonymous) FTP'ed to (not PAS 
mode) if anyone wants to see it working. On the FTP server are the 
individual web page files which can be updated, copied and deleted 
(but please don't change anything...). Since the FTP here is 
designed for maintenance (web page mods etc.) it supports only a 
single connection at a time whereas the web server 
(http://212.254.22.36:8084 will do loads in parallel). In fact this 
device also supportes software uploads and also debugging via the 
internet and is being used for real development whenever there is an 
Internet connection available - saves having to carry the hardware 
around if on the move...). It can also be Telnet'ed to, but both web 
server and Telnet are password protected; I wonder whether someone 
can still get in...?

The advantage of this solution (although it presently doesn't have a 
wide platform support) is that it includes a simulator which means 
that real network traffic can be recorded using Ethereal and played 
back through the code. It makes for much improved development and 
debug support since it is possible to debug occurances at remote 
locations as long as there was an Ethereal recording of the events 
which can be supplied - playing back through the code using the 
simulator allows all details to be analysed and code improvements 
and corrections even to be verified. It is also very helpful when 
learning the protocols and code since the frames can be easily 
displayed in the debugger and each step analysed - very useful for 
educational establishments...

Regards

Mark Butcher

Hi Richard

I know that you ported FreeRTOS to the SAM7X - we did have a few 
mail exchanges about it and other things in the past.

It seems as though the AT91SAM7 Yahoo group no longer exists - at 
least I haven't been able to find it for a few weeks now - I get 
only an error message and searching for it also turns up a blank 
(very strange because it was an interesting group).

As it happens I have 'finally' got the SAM7x chips (engineering 
samples) and they are soldered onto new boards and beginning to do 
some stuff.

I am hoping to complete a port by the beginning of next week but my 
first experiences have shown that things don't always work out as 
well as expected and it may well take a biiiit longer. I have a 
couple of questions:
1. Do you know where this topic is now being discussed. I don't 
really know of any other good active group.
2. Did you do a project for IAR? I am using this with J-Link 
debugger and have lost a lot of time because as soon as I had 
stopped the code my PIT interrupt would never come again. Firstly it 
made it difficult to know what was going on when initially getting 
the interrupt up and running (not knowing that the debugger was 
causing problems...) and then having to restart after a breakpoint 
was also very annoying.
I think that I know why because after closing a memory window it 
seems to work (quite) well. It seems as though the memory window 
update was causing the PIT registers to be read and resetting 
(interrupt related) things in the process. Do you know of this 
problem and work-arounds???
3. Presently I am loading part of the project into RAM so that the 
debugging works well but the code size will not always allow this - 
it will soon have to go into FLASH. Do you have any experience / 
tips about how it is best to go about this ? [I would like to 
generally use the serial debug interface and debug difficult cases 
in FLASH with J-Link].
4. My project needs serial and Ethernet and I have a Micrel PHY. I 
supose you used the DAVICON on the Eval board. Do you have any tips 
about things to watch out for in the process?

Sorry that not directly LP2000 related (ATMEL standing in until the 
new LPC Ethernet part is available) but I think that a lot of ATMEL 
group members are also lurking around here..

Regards

Mark Butcher
www.mjbc.ch



--- In lpc2000@yahoogroups.com, "FreeRTOS Info" <nospam@F...> wrote:
>
> 
> 
> > > Here too.
> > > Win XP Pro.
> > > Firefox 1.5
> > >
> > > http://82.32.114.142:47821/
> > > http://82.32.114.142:47820/
> > > http://82.32.114.142:47822/cgi/tcp
> > > http://82.32.114.142:47822/cgi/rtos
> > >
> > > all of them works fine.
> >
> >
> > Hmm.    First round the second listed was giving me "The 
document contains
> > no data."  After multiple tries through the list then the second 
worked
> and
> > the first start complaining.  Are all of these running uIP I 
wonder?
> >
> > XP
> > Firefox 1.0.7
> 
> 
> The 47820 port is using a WizNET I2C interface.
> 
> The 47821 is Pauls uIP demo bit banging a Crystal LAN running as a 
task
> under FreeRTOS (LPC).
> 
> The 47822 is uIP running with interrupts and DMA on a SAM7X.
> 
> The number of simultaneous connections is limited (#define in the 
code).  If
> you look at a page that sends lots of small packets then each 
takes a
> connection.  I imagine that posting the addresses here is 
generating several
> simulations hits, so maybe its just running out of connections 
hence the
> intermittence.
> 
> All works fine for me, but the boards are only a few feet away.  
Also I'm

> using IE rather than Firefox.
> 
> Regards,
> Richard.
> 
> http://www.FreeRTOS.org
>

--- In lpc2000@yahoogroups.com, "Mark Butcher" <M_J_Butcher@I...> wrote:
> It seems as though the AT91SAM7 Yahoo group no longer exists - at 
> least I haven't been able to find it for a few weeks now - I get 
> only an error message and searching for it also turns up a blank 
> (very strange because it was an interesting group).

Try the following:

http://groups.yahoo.com/group/AT91SAM/

Regards,

PJE

>It seems as though the AT91SAM7 Yahoo group no longer exists - at
>least I haven't been able to find it for a few weeks now - I get
>only an error message and searching for it also turns up a blank
>(very strange because it was an interesting group).

Seems to work for me:  http://groups.yahoo.com/group/AT91SAM/

Not as active as the LPC group.

>As it happens I have 'finally' got the SAM7x chips (engineering
>samples) and they are soldered onto new boards and beginning to do
>some stuff.

Odd how long that has taken.  I thought they were more available than that.


>I am hoping to complete a port (non-pre-emptive port, so rather
>easier) by the beginning of next week but my first experiences have
>shown that things don't always work out as well as expected. I have
>a couple of questions:
>1. Do you know where this topic is now being discussed. I don't
>really know of any other good active group.

You could try http://www.at91.com.  There is a forum, but I have not
used/read it more than once or twice so I don't know how active it is.

>2. Did you do a project for IAR? I am using this with J-Link
>debugger and have lost a lot of time because as soon as I had
>stopped the code my PIT interrupt would never come again. Firstly it
>made it difficult to know what was going on when initially getting
>the interrupt up and running (not knowing that the debugger was
>causing problems...) and then having to restart after a breakpoint
>was also very annoying.

I have used the J-Link without too many problems.  It occasionally hangs up
and requires me to shut down the IDE in order to make a connection again,
but this is only when downloading code.  Check the .mac file that you are
using (the macros that are run on debug events).  There seem to be a lot
around and some are not full implementations.  Original versions did not
reset interrupts properly so the debug session would only work once per
board reset.


>I think that I know why because after closing a memory windows it
>seems to work (quite) well. It seems as though the memory windows
>update was causing the PIT registers to be read and resetting
>(interrupt related) things in the process. Do you know of this
>problem and work-arounds???

Should have read that before writing the above ....

Never come across this problem.  I use the memory window quite extensively,
but maybe not over the PIT register region.


>3. Presently I am loading part of the project into RAM so that the
>debugging works well but the code size will not always allow this -
>it will soon have to go into FLASH. Do you have any experience /
>tips about how it is best to go about this ? [I would like to
>generally use the serial debug interface and debug difficult cases
>in FLASH with J-Link].

I have not used the serial debug interface, and think there may be some
conflict with using the PIT for the timer.  Can't quite remember without
checking the data sheet.


>4. My project needs serial and Ethernet and I have a Micrel PHY. I
>supose you used the DAVICON on the Eval board. Do you have any tips
>about things to watch out for in the process?

Sorry, never used a Micrel PHY.  I know the original SAM7X Atmel eval boards
had a timing error in the design that meant RMII interface did not work
properly, so I hope you didn't copy the design ;-)   MII works fine.


Regards,
Richard.

http://www.FreeRTOS.org

PeterElliot wrote:
> --- In lpc2000@yahoogroups.com, "Mark Butcher" <M_J_Butcher@I...> wrote:
>> It seems as though the AT91SAM7 Yahoo group no longer exists - at 
>> least I haven't been able to find it for a few weeks now - I get 
>> only an error message and searching for it also turns up a blank 
>> (very strange because it was an interesting group).
> 
> Try the following:
> 
> http://groups.yahoo.com/group/AT91SAM/
> 

Also for SAM7X + I/P
The discussion can be seen in the archive at the bottom of the page here:
http://www.egnite.de/pipermail/en-nut-discussion/2006-January/thread.html

The group is also eagerly waiting to see the LPC offering with ethernet.

Don