>> 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.
lwIpWeb - no webpage built
Started by ●January 19, 2009
Reply by ●January 22, 20092009-01-22
Reply by ●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
http://jumentum.sourceforge.net/
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.
>
>
>
>
>
>
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
http://jumentum.sourceforge.net/
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 ●January 23, 20092009-01-23
> 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.
> 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 ●January 23, 20092009-01-23
>> The port can be found at:
>> http://cvs.savannah.nongnu.org/viewvc/contrib/ports/c16x ...
That's just emac files. Don't care about that.
>> 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:
http://savannah.nongnu.org/bugs/?group=lwip
Best Regards, Chris.
>> http://cvs.savannah.nongnu.org/viewvc/contrib/ports/c16x ...
That's just emac files. Don't care about that.
>> 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:
http://savannah.nongnu.org/bugs/?group=lwip
Best Regards, Chris.
Reply by ●January 26, 20092009-01-26
> 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.
> 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.
Reply by ●October 19, 20092009-10-19
