After writing this post it made me think that the fault was not in the LWIP configuration but in the way that I was handling the file system. I was reusing the same file handle for all of the files, rather than
creating a new handle for each requested file.
I think that it now works. Well my test page is loading correctly.
For what it is worth and reading on internet posts other peoples issues, I can confirm that it absolutely possible to serve uncompressed html, pdf or any other files of any size from an SD card using LWIP and
limited RAM.
I used the Xilinx app note xapp1026.pdf as the basis for my web server, it was extremely simple to follow. And easy enough to port to the NXP device and EFSL
http://china.xilinx.com/support/documentation/application_notes/xapp1026.pdf
Thanks for reading.
From: Marshall Brown
Sent: Tuesday, 2 April 2013 9:43 p.m.
To: 'address@hidden'
Subject: Serving httpd files sequentially
Hi there
I have LWIP 1.4.1 successfully running on an LPC1768 with no OS, I have used the upper 32 of RAM (of a total of 64k) for LWIP with the following options set (check the attached lwipopts.h for further settings)
#define
MEM_SIZE (31 * 1024)
#define MEMP_MEM_MALLOC 1
//MKB added to try and clean up the memory a bit
My understanding of the above define “MEMP_MEM_MALLOC” puts everything on the heap, which is fine for my application
I am trying to serve a standard web page from an SD card, the page has links to 3 or 4 image files. I’ve tried so many versions of contrib httpd and they all come unstuck when the browser requests “GET /file 1” followed by “GET /file 2”
when LWIP is still serving or ACK the first file. I’m not sure if it is a function of LWIP or the SD card (EFSL) that is not happy, but the files are coming out corrupted.
I would like to know if there is a way to prevent the browser from requesting a file before the web server has finished serving the previous one? I have tried the following options (as well as MANY others)
#define
TCP_LISTEN_BACKLOG 1
//Default = 0 == off 0 means "disabled". In this case, backlog is limited by the number of PCBs.
//this means we use all our memory up accepting listening pcb's then can't service them so we limit to 1
#define TCP_DEFAULT_LISTEN_BACKLOG 4
But the PCBs remain in the CLOSE-WAIT state for such a long time they can’t be reused.
The screen shot below shows the files being served and the subsequent corruption. Any help would be appreciated.
Regard
Marshall
