EmbeddedRelated.com
Forums

lwIP Web, lwIP port to MCB2300

Started by kurt_sterckx January 22, 2007
I have uploaded the file lwIPWeb.zip to the forum. It contains a port
of the lwIP TCP/IP stack to the LPC2368/LPC2378 without a OS. It
contains a very simple web server application. It uses a slightly
modified version of the easyWeb ethernet driver. It can be compiled
with WinARM.

Please read the readme.txt in the zip package.

How fun,

Kurt

An Engineer's Guide to the LPC2100 Series

kurt_sterckx wrote:
> I have uploaded the file lwIPWeb.zip to the forum. It contains a port
> of the lwIP TCP/IP stack to the LPC2368/LPC2378 without a OS. It
> contains a very simple web server application. It uses a slightly
> modified version of the easyWeb ethernet driver. It can be compiled
> with WinARM.
>

Hi Kurt,

In your portlcd.c file you mention it's states based off of the NXP
example (portlcd.c). The NXP example code is copyrighted material.
Your code only changes functions to static and you removes header
dependencies. The contents of the functions are identical. I'm pretty
sure you need to include the NXP copyright in your file "based" off of
the copyrighted NXP code.

The file I just noticed this with was portlcd.c. I have not looked at
any of your other files.

Any copyright experts care to weigh in?
Joel
Hi Joel,

It wasn't my intention to remove the copyright from NXP, it was done
during the cleanup fase, late and to quick. You can see the
copyright in the header file (portlcd.h). I can't find a option on
the forum to change a file, so I can't update the zip. I am sorry
for this mistake and hope that NXP can understand it.

Kurt

--- In l..., Joel Winarske wrote:
>
> kurt_sterckx wrote:
> > I have uploaded the file lwIPWeb.zip to the forum. It contains a
port
> > of the lwIP TCP/IP stack to the LPC2368/LPC2378 without a OS. It
> > contains a very simple web server application. It uses a
slightly
> > modified version of the easyWeb ethernet driver. It can be
compiled
> > with WinARM.
> >
>
> Hi Kurt,
>
> In your portlcd.c file you mention it's states based off of the
NXP
> example (portlcd.c). The NXP example code is copyrighted
material.
> Your code only changes functions to static and you removes header
> dependencies. The contents of the functions are identical. I'm
pretty
> sure you need to include the NXP copyright in your file "based"
off of
> the copyrighted NXP code.
>
> The file I just noticed this with was portlcd.c. I have not
looked at
> any of your other files.
>
> Any copyright experts care to weigh in?
> Joel
>
I have updated the GNUEasyWeb.zip and lwIPWeb.zip file so it now has
the copyright of NXP in portlcd.c and LPC23xx.h. Please upload this
files, even when you already have uploaded a previous version, so
that the copyrights are correct.

Regards,

Kurt
--- In l..., "kurt_sterckx"
wrote:
>
> Hi Joel,
>
> It wasn't my intention to remove the copyright from NXP, it was
done
> during the cleanup fase, late and to quick. You can see the
> copyright in the header file (portlcd.h). I can't find a option on
> the forum to change a file, so I can't update the zip. I am sorry
> for this mistake and hope that NXP can understand it.
>
> Kurt
>
> --- In l..., Joel Winarske wrote:
> >
> > kurt_sterckx wrote:
> > > I have uploaded the file lwIPWeb.zip to the forum. It contains
a
> port
> > > of the lwIP TCP/IP stack to the LPC2368/LPC2378 without a OS.
It
> > > contains a very simple web server application. It uses a
> slightly
> > > modified version of the easyWeb ethernet driver. It can be
> compiled
> > > with WinARM.
> > >
> >
> > Hi Kurt,
> >
> > In your portlcd.c file you mention it's states based off of the
> NXP
> > example (portlcd.c). The NXP example code is copyrighted
> material.
> > Your code only changes functions to static and you removes
header
> > dependencies. The contents of the functions are identical. I'm
> pretty
> > sure you need to include the NXP copyright in your file "based"
> off of
> > the copyrighted NXP code.
> >
> > The file I just noticed this with was portlcd.c. I have not
> looked at
> > any of your other files.
> >
> > Any copyright experts care to weigh in?
> >
> >
> > Joel
>
I got lwIPWeb to work on a MCB2300 board (thanks to Kurt). However,
when I tried doing TCP, I found a problem. When I wrote two
consecutive packets of 35 bytes each using tcp_write, the packets got
enqueued and then sent out. The actual TCP packet received has length
field being 70 bytes, but the actual TCP data has 71 bytes. There is
an extra byte between the two 35 byte segments. When I traced the
source code, the problem appears in CopyToFrame_EMAC. It expects even
number of bytes to be copied. If it is called with an odd number of
bytes, it extends the length by one. That results in an extra byte in
the TCP data while the length is unchanged. So we end up with
Sequence/Acknowledge numbers problem at the receiving end.

Has anybody encountered this problem? CopyToFrame_EMAC is only copying
data to the buffers in EtherRAM, why are we restricted to 16-bit copies?

Any help would be appreciated.
Hi,

Would you mind copying the project to the Files area like uIP project so
other people can contribute in finding/fixing the bugs and to allow saving
time.

Thanks,

Kerem

From: l... [mailto:l...] On Behalf Of
sam_bbi
Sent: Monday, May 21, 2007 7:41 PM
To: l...
Subject: [lpc2000] Re: lwIP Web, lwIP port to MCB2300

I got lwIPWeb to work on a MCB2300 board (thanks to Kurt). However,
when I tried doing TCP, I found a problem. When I wrote two
consecutive packets of 35 bytes each using tcp_write, the packets got
enqueued and then sent out. The actual TCP packet received has length
field being 70 bytes, but the actual TCP data has 71 bytes. There is
an extra byte between the two 35 byte segments. When I traced the
source code, the problem appears in CopyToFrame_EMAC. It expects even
number of bytes to be copied. If it is called with an odd number of
bytes, it extends the length by one. That results in an extra byte in
the TCP data while the length is unchanged. So we end up with
Sequence/Acknowledge numbers problem at the receiving end.

Has anybody encountered this problem? CopyToFrame_EMAC is only copying
data to the buffers in EtherRAM, why are we restricted to 16-bit copies?

Any help would be appreciated.