> Of course I improved the server with parsing of HTTP
requests to be able to access more files and with support for persistent
connections (default for HTTP/1.1) to improve performance when frequenlty
accessing small files. Can you post this HTTP Server into this Groups files ?
> But beyond the multi socket issue, the other lwIP
issues I could not resolve. A lot of data copy going on and
> most of it by single byte. They have buffers aligned to 2 bytes instead of 4.
I kept running into things that just
> did not work right, or crashed. Yes I can get it to pass a few packets, but
when I throw anything major at it, ...
> problems.
lwIP is designed to minimise data copying. The stack will only pass pointers to
data to be sent. Of course there is an internet checksum routine that handles
every byte and routine to copy the data to network interface. It is a wise itea
for the two functions to work on largest posible size of data (32 bit on a LPC)
and to be optimised for speed (perhaps written in assemler). In LPC2300 DMA
could be used.
For efficiently copying data, it is good to be 2 or even 4 bytes alligned as you
mentioned. In lwIP data will also be copied when a flag is sent od tcp_write.
This is often used with dynamic generated data as it is simpler to use, than
have to track details of which data was acknowledge and which not.
About the problems: As I discovered many ports have problems with data alignment
and odd sized data. This two factors must be accounted for when writing the code
to make it robust.
>> When a TCP connection is open, the HTTP server code
reserves a control structure to handle the request.
>> A reference to this structure is saved to the lwIP's arg in order to be
retrieved on subsequent calls.
>> Pointer to the file, index of bytes left and so on are all stored in the
structure.
>> The number of simultaneous HTTP requests is therefore only limited by the
amount of free RAM
>> and of course lwIP's settings. Thanks to the approach, programming is
not much harder compared to single connection support.
The Devil's in the details. That's the part I was asking about, how
connections are processed: the httpserver code. I'd like to see the code
to test. Everything I see listed for lwIP is always given as 'basic'
examples, single socket. If you have an httpserver routine that handles
multiple sockets, you should upload it up on the contrib/apps section. A lot of
people would like to see that.
But beyond the multi socket issue, the other lwIP issues I could not resolve. A
lot of data copy going on and most of it by single byte. They have buffers
aligned to 2 bytes instead of 4. I kept running into things that just did not
work right, or crashed. Yes I can get it to pass a few packets, but when I
throw anything major at it, ... problems. If anyone has a version that they
think really works, I wish they would post it on the site so it can be throughly
tested (PCATTCP, WSTTCP). There are 26 open bugs listed on the lwIP site:
> I'd be very interested to see your
webserver/http code section. What I see
> cannot handle multiple socket connections. I'd be very interested to
see
> the code you are using to process the connection.
I have used the c16x port from Christian Scheurer which also features a very
basic web server. This was first on LPC2214 with NE2000 compatible card. Later I
took EMAC driver from lwIpWep.zip and ported to LPC2368.
The port can be found at: http://cvs.savannah.nongnu.org/viewvc/contrib/ports/c16x/?root=lwip
When a TCP connection is open, the HTTP server code reserves a control structure
to handle the request. A reference to this structure is saved to the lwIP's
arg in order to be retrieved on subsequent calls. Pointer to the file, index of
bytes left and so on are all stored in the structure. The number of simultaneous
HTTP requests is therefore only limited by the amount of free RAM and of course
lwIP's settings. When a connection is closed, its control structure is
freed. Thanks to the approach, programming is not much harder compared to single
connection support.
Of course I improved the server with parsing of HTTP requests to be able to
access more files and with support for persistent connections (default for
HTTP/1.1) to improve performance when frequenlty accessing small files.
Reply by profdc9●January 22, 20092009-01-22
You are probably sending the initialization commands to the wrong PHY
address. There are 31 phy addresses between 1 and 31. If there is no
PHY responding to the address you send over the RMII bus, then you get
0xFFFF as the response to any command.
If you want an example of using the Micrel KS8721, look at the
Jumentum project lpcmac.c code
My code scans all of the addresses to find the one that does not
respond 0xFFFF.
Dan
--- In l..., GARAT Herv wrote: >
> Hi all,
>
> I'm getting a sample code running on EA's LPC2468-16 OEM BOARD
and freertos. >
> When I try with the LPC2478 OEM BOARD, it work fine, but with the 2468 I can't read the PHY ID, I allways read 0xFFFF. The PHY are
different, on the 2478 it's an DP83848(NS) and on the 2468 it's an
KSZ8001L(MICREL). >
> Can anybody provide sample code, to see if this PHY work really!
>
> Regards,
>
> Hervbr />
>
>
>
>
> ________________________________
> From: sig5534
> To: l...
> Sent: Thursday, January 22, 2009 1:16:27 AM
> Subject: [lpc2000] Re: lwIpWeb - no webpage built
>
> > It is the first time that I read such a "reserved comment" about
> > lwIP.;-) Very interesting for me.
> > I am not very familiar with TCP/IP and expected a more or less
> > ready-to-use package. Most users wrote that they got it working.
>
> I would not put lwIP in the 'ready to use' category, not even the so
> called experts in the lwIP fan club would not go that far. There are
> very few ports of lwIP running on the LPC2468. Only about 3 I know
> of, one without an RTOS. But I must point out, 'running' is a term
> that is highly abused here. If you are talking about sending one
> packet, waiting for it to finish, before being able to send another
> packet, I guess someone can call that 'running'. But if you are
> talking about sending a real html file containing graphics content
> links, etc, I think the term 'crashing' is more accurate.
>
> > The reason why I don't fancy an RTOS is because my application needs
> > to run in real time and I expect that an RTOS would waste too many
> > resources (time).
>
> No. Yes uLinux is big, forget that unless you have ext RAM,ROM etc.
> However something like FreeRTOS is entirely different. I am using
> that and it is small, fast, and well done. That only requires 5-20k
> RAM. Not big at all, and is very helpful in many ways. Very easy to
> setup. 1 hour. I have no problem recommending that at all.
>
> > The shortest process cycle in my application is 20ms. During each
> > cycle I would like to transmit about 2000 bytes and receive
> > occasionally some commands. That should be no problem from the
> > transfer rate's point of view, but is it realistic to use TCP/IP for
> > that?
> > I don't really know. That is why I wanted to test the raw TCP/IP
> > interface which is described as faster and small in code size and
> > memory usage.
> > Perhaps my idea is an irrealistic illusion, so I would appreciate
> > everybody's opinion on that.
>
> Boy, where to begin here. Huge subject. Doing Enet/IP is 100 times
> more difficult than USB. Unless you want to spend a year writing code
> and debugging, you will likely end up using some other prewritten
> TCP/IP code.
>
> Ethernet is a multilayered stack of protocols. UDP is the lowest
> level IP layer, but it's data is not reliable. TCP is the next
> higher layer, and it manages UDP packets to make them reliable. Yes
> it is about the lowest level you can use for reliable data transfer.
>
> > From your experience, would you say that TCP/IP with an RTOS should
> > be able to run with an application as described above?
>
> Sure, if you have a TCP/IP stack that actually works. But you need
> an OS or at least some kind of minimal task manager. That is really
> a must with Enet.
>
> Think of it this way. What you are trying to do is very simple based
> on how you describe it: just send 2000 bytes. However remember that
> you are connecting to a very complex network, and it has other
> ideas. When it fires off broadcasts, ARPs, SYNs, ACKs, checksums,
> etc. to your Enet device, it has to answer. That's where the
> complexity comes from. The part you're using it for IS easy. But
> the other stuff you have to support on top of it makes it very
> complex.
>
> Hope that helps.
>
> Best Regards, Chris.
>
>
>
>
>
>
Reply by HM2●January 22, 20092009-01-22
>> I have lwIP working on LPC2368 with DP83848 and
without an OS.
>> The software features HTTP/1.1 server also serving pages with graphics and AJAX. >> The TCP window is larger than one segment.
I'd be very interested to see your webserver/http code section. What I
see
cannot handle multiple socket connections. I'd be very interested to
see
the code you are using to process the connection.
Regards, Chris.
Reply by ●January 22, 20092009-01-22
I have lwIP working on LPC2368 with DP83848 and without an OS.
The software features HTTP/1.1 server also serving pages with graphics and AJAX.
The TCP window is larger than one segment.
The software is fully event (interrupt) driven, no pulling. When a request,
response comes from the network, the lwIP will deal with it in the interrupt
routine.
Of course this poses a problem if you need fast response to interrupts. In that
case you have to use nested interrupts or use FIQ, besides IRQ.
For me doing Ethernet is much more simpler than USB. I understand it more
thorougly. On the other hand I agree that lwIP is not ready to use. You have to
write PHY driver, adjust the settings and so on.
Reply by HM2●January 22, 20092009-01-22
>> I'm getting a sample code running on EA's
LPC2468-16 OEM BOARD and freertos. >> When I try with the LPC2478 OEM BOARD, it work fine,
but with the 2468 I
>> can't read the PHY ID, I allways read 0xFFFF. The PHY are different,
on the 2478 it's an >> DP83848(NS) and on the 2468 it's an
KSZ8001L(MICREL).
'sample' code does not say much, but every enet interface is
typically
written for a particular Phy. The Phy ID is certainly different, the Phy
adr may be as well, and the Phy register used to read back the link speed
and duplex is generally different with all PHYs. Those are the areas you
need to check and/or modify in the emac code.
>> Can anybody provide sample code, to see if this PHY
work really!
Get the data sheet for the KSZ8001L and modifiy the code yourself. It's
really not that hard.
Chris.
Reply by ●January 22, 20092009-01-22
Hi all,
I'm getting a sample code running on EA's LPC2468-16 OEM BOARD and
freertos.
When I try with the LPC2478 OEM BOARD, it work fine, but with the 2468 I
can't read the PHY ID, I allways read 0xFFFF. The PHY are different, on the
2478 it's an DP83848(NS) and on the 2468 it's an KSZ8001L(MICREL).
Can anybody provide sample code, to see if this PHY work really!
Regards,
Hervbr />
________________________________
From: sig5534
To: l...
Sent: Thursday, January 22, 2009 1:16:27 AM
Subject: [lpc2000] Re: lwIpWeb - no webpage built
> It is the first time that I read such a "reserved
comment" about
> lwIP.;-) Very interesting for me.
> I am not very familiar with TCP/IP and expected a more or less
> ready-to-use package. Most users wrote that they got it working.
I would not put lwIP in the 'ready to use' category, not even the so
called experts in the lwIP fan club would not go that far. There are
very few ports of lwIP running on the LPC2468. Only about 3 I know
of, one without an RTOS. But I must point out, 'running' is a term
that is highly abused here. If you are talking about sending one
packet, waiting for it to finish, before being able to send another
packet, I guess someone can call that 'running'. But if you are
talking about sending a real html file containing graphics content
links, etc, I think the term 'crashing' is more accurate.
> The reason why I don't fancy an RTOS is because
my application needs
> to run in real time and I expect that an RTOS would waste too many
> resources (time).
No. Yes uLinux is big, forget that unless you have ext RAM,ROM etc.
However something like FreeRTOS is entirely different. I am using
that and it is small, fast, and well done. That only requires 5-20k
RAM. Not big at all, and is very helpful in many ways. Very easy to
setup. 1 hour. I have no problem recommending that at all.
> The shortest process cycle in my application is 20ms.
During each
> cycle I would like to transmit about 2000 bytes and receive
> occasionally some commands. That should be no problem from the
> transfer rate's point of view, but is it realistic to use TCP/IP for
> that?
> I don't really know. That is why I wanted to test the raw TCP/IP
> interface which is described as faster and small in code size and
> memory usage.
> Perhaps my idea is an irrealistic illusion, so I would appreciate
> everybody's opinion on that.
Boy, where to begin here. Huge subject. Doing Enet/IP is 100 times
more difficult than USB. Unless you want to spend a year writing code
and debugging, you will likely end up using some other prewritten
TCP/IP code.
Ethernet is a multilayered stack of protocols. UDP is the lowest
level IP layer, but it's data is not reliable. TCP is the next
higher layer, and it manages UDP packets to make them reliable. Yes
it is about the lowest level you can use for reliable data transfer.
> From your experience, would you say that TCP/IP with
an RTOS should
> be able to run with an application as described above?
Sure, if you have a TCP/IP stack that actually works. But you need
an OS or at least some kind of minimal task manager. That is really
a must with Enet.
Think of it this way. What you are trying to do is very simple based
on how you describe it: just send 2000 bytes. However remember that
you are connecting to a very complex network, and it has other
ideas. When it fires off broadcasts, ARPs, SYNs, ACKs, checksums,
etc. to your Enet device, it has to answer. That's where the
complexity comes from. The part you're using it for IS easy. But
the other stuff you have to support on top of it makes it very
complex.
Hope that helps.
Best Regards, Chris.
Reply by tcirobot●January 21, 20092009-01-21
--- In l..., "sig5534" wrote: >
> > It is the first time that I read such a "reserved comment" about
> > lwIP.;-) Very interesting for me.
> > I am not very familiar with TCP/IP and expected a more or less
> > ready-to-use package. Most users wrote that they got it working.
>
> I would not put lwIP in the 'ready to use' category, not even the so
> called experts in the lwIP fan club would not go that far. There are > very few ports of lwIP running on the LPC2468. Only
about 3 I know
> of, one without an RTOS. But I must point out, 'running' is a term
> that is highly abused here. If you are talking about sending one
> packet, waiting for it to finish, before being able to send another
> packet, I guess someone can call that 'running'. But if you are
> talking about sending a real html file containing graphics content
> links, etc, I think the term 'crashing' is more accurate.
>
> > The reason why I don't fancy an RTOS is because my application needs > > to run in real time and I expect that an RTOS would
waste too many
> > resources (time).
>
> No. Yes uLinux is big, forget that unless you have ext RAM,ROM etc.
> However something like FreeRTOS is entirely different. I am using
> that and it is small, fast, and well done. That only requires 5-20k
> RAM. Not big at all, and is very helpful in many ways. Very easy to
> setup. 1 hour. I have no problem recommending that at all.
>
> > The shortest process cycle in my application is 20ms. During each
> > cycle I would like to transmit about 2000 bytes and receive
> > occasionally some commands. That should be no problem from the
> > transfer rate's point of view, but is it realistic to use TCP/IP for > > that?
> > I don't really know. That is why I wanted to test the raw TCP/IP
> > interface which is described as faster and small in code size and
> > memory usage.
> > Perhaps my idea is an irrealistic illusion, so I would appreciate
> > everybody's opinion on that.
>
> Boy, where to begin here. Huge subject. Doing Enet/IP is 100 times
> more difficult than USB. Unless you want to spend a year writing code > and debugging, you will likely end up using some
other prewritten
> TCP/IP code.
>
> Ethernet is a multilayered stack of protocols. UDP is the lowest
> level IP layer, but it's data is not reliable. TCP is the next
> higher layer, and it manages UDP packets to make them reliable. Yes
> it is about the lowest level you can use for reliable data transfer.
>
> > From your experience, would you say that TCP/IP with an RTOS should > > be able to run with an application as described
above?
>
> Sure, if you have a TCP/IP stack that actually works. But you need
> an OS or at least some kind of minimal task manager. That is really
> a must with Enet.
>
> Think of it this way. What you are trying to do is very simple based
> on how you describe it: just send 2000 bytes. However remember that
> you are connecting to a very complex network, and it has other
> ideas. When it fires off broadcasts, ARPs, SYNs, ACKs, checksums,
> etc. to your Enet device, it has to answer. That's where the
> complexity comes from. The part you're using it for IS easy. But
> the other stuff you have to support on top of it makes it very
> complex.
>
> Hope that helps.
>
> Best Regards, Chris.
>
Chris is right. This can quickly become a complicated discussion. Here
is a message (from this group) that might give you a little guidance
about TCP/IP, micro, and RTOS usage...
