Hello,
my aim is to get the lwIP-Stack running on EA's LPC2468-16 OEM board
using Rowley's Crosswork.
So far without any success: http_recv_callback() - the function that
sends the webpage - is never invoked.
This is what I did up to now:
1. I created an empty project under Crossworks using the install package.
2. I took the .c- and .h-files from lwIPWeb.zip from this forum and
added them to the project.
2.a Then emac.h has been modified: PINSEL2 = 0x50150105; to
compensate the bug of rev. '-'
2.b inet6.c has not been used in the project, since the definition
of inet_chksum_pseudo() was slightly different from the declaration in
inet.h and caused a compiler error. I suppose that cancelling it from
the project doesn't matter as I couldn't find it in the original
MakeFile either.
2.c LCD has not been used.
For testing the programme I used MCB2300.
The LEDs are flashing at a rate of 1s, so the ticker timer and
interrupt handler should be ok.
Activating the browser to see the webpage ended up with a time-out.
WireShark sends "Who has 192.168.115.241?" (I set this ip address in
main.c.) but doesn't seem to get an answer.
On the embedded side I can track the ARP request down to
ethernetif_handlepackets() in main.c which then detects
ETHTYPE_IP=0x800 for this ARP request (ETHTYPE_ARP=0x806 never is
received).
The story comes to an end when
ip_input(...) (module ip.c)
is reached.
When it comes to the place where the version is checked (in ip_input(..)
if(IPH_V(iphdr != 4) // "IP packet dropped due to bad version
// number...
'4' is not detected and the function returns with ERR_OK.
I followed this procedure several times - always with the same result.
Can anybody advice how to proceed?
Or even better:
Can anybody provide sample code with lwIP running under Rowley but
without any RTOS?
Henry
lwIpWeb - no webpage built
Started by ●January 19, 2009
Reply by ●January 19, 20092009-01-19
>> my aim is to get the lwIP-Stack running on EA's
LPC2468-16 OEM board using Rowley's Crosswork.
>> Can anybody provide sample code with lwIP running under Rowley but without any RTOS?
I wrote a port for LPC2468 for lwIP-1.30 and FreeRTOS, and it runs. However lwIP itself has problems. Much more I could say, but trying to be politically correct I will simply say: I do not recommend lwIP. I am rewriting NicheLite for GCC right now, and I highly recommend Niche.
As for no RTOS, that is not really practical for any TCP/IP stack. If you want to do IP, you should expect to use an RTOS. There are far too many things going on to manage without a task OS. Using an RTOS is trivial. The TCP/IP stack is where the work is.
Chris.
>> Can anybody provide sample code with lwIP running under Rowley but without any RTOS?
I wrote a port for LPC2468 for lwIP-1.30 and FreeRTOS, and it runs. However lwIP itself has problems. Much more I could say, but trying to be politically correct I will simply say: I do not recommend lwIP. I am rewriting NicheLite for GCC right now, and I highly recommend Niche.
As for no RTOS, that is not really practical for any TCP/IP stack. If you want to do IP, you should expect to use an RTOS. There are far too many things going on to manage without a task OS. Using an RTOS is trivial. The TCP/IP stack is where the work is.
Chris.
Reply by ●January 21, 20092009-01-21
Thank you, Chris.
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.
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). (I tested uClinux and found that it was not suitable
for my application.)
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.
You suggest to always use an RTOS and in fact I did not find a sample
without an RTOS (besides lwIpWeb from the files section).
>From your experience, would you say that TCP/IP with an RTOS should be
able to run with an application as described above?
Henry
--- In l..., "HM2" wrote:
>
> >> my aim is to get the lwIP-Stack running on EA's LPC2468-16 OEM
board using Rowley's Crosswork.
> >> Can anybody provide sample code with lwIP running under Rowley
but without any RTOS?
>
> I wrote a port for LPC2468 for lwIP-1.30 and FreeRTOS, and it runs.
However lwIP itself has problems. Much more I could say, but trying
to be politically correct I will simply say: I do not recommend lwIP.
I am rewriting NicheLite for GCC right now, and I highly recommend Niche.
>
> As for no RTOS, that is not really practical for any TCP/IP stack.
If you want to do IP, you should expect to use an RTOS. There are
far too many things going on to manage without a task OS. Using an
RTOS is trivial. The TCP/IP stack is where the work is.
>
> Chris.
>
>
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.
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). (I tested uClinux and found that it was not suitable
for my application.)
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.
You suggest to always use an RTOS and in fact I did not find a sample
without an RTOS (besides lwIpWeb from the files section).
>From your experience, would you say that TCP/IP with an RTOS should be
able to run with an application as described above?
Henry
--- In l..., "HM2" wrote:
>
> >> my aim is to get the lwIP-Stack running on EA's LPC2468-16 OEM
board using Rowley's Crosswork.
> >> Can anybody provide sample code with lwIP running under Rowley
but without any RTOS?
>
> I wrote a port for LPC2468 for lwIP-1.30 and FreeRTOS, and it runs.
However lwIP itself has problems. Much more I could say, but trying
to be politically correct I will simply say: I do not recommend lwIP.
I am rewriting NicheLite for GCC right now, and I highly recommend Niche.
>
> As for no RTOS, that is not really practical for any TCP/IP stack.
If you want to do IP, you should expect to use an RTOS. There are
far too many things going on to manage without a task OS. Using an
RTOS is trivial. The TCP/IP stack is where the work is.
>
> Chris.
>
>
Reply by ●January 21, 20092009-01-21
I don't want to get too far off topic, but your comments are
interesting.
> The reason why I don't fancy an RTOS is because my
> application needs to run in real time
As in "Real Time" operating system.
> and I expect that an
> RTOS would waste too many resources (time).
This really depends on the application. Sometimes an RTOS is wasteful, but
if when not using pre-emption you are instead polling inputs an RTOS can
free up absolutely masses of processing time. When polling an input the
processor is using lots of cycles when there is nothing to do. If instead
you use an RTOS then processing cycles are only used when there is actually
something that needs to be done.
Of course its not that clear cut and there is more than one way to skin a
cat, and I'm not an advocate of always using an RTOS, but of using the best
tools for the job in hand. Its just interesting some of the comments that
are made.
> (I tested uClinux
> and found that it was not suitable for my application.)
I thought we were talking about RTOS :o)
A lot has to do with the architecture on which the code is running too. For
example, on a Cortex M3 I can get jitter in interrupt timings down to 120ns
(50Mhz clock) - all of which is down to the tail chaining on the processor
short cutting interrupt entry and nothing to do with the RTOS. I took these
measurements when somebody told me they could not possibly use an RTOS for a
motor control app because they needed a jitter of less than 1uS.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ www.freertos.org/Documentation/FreeRTOS-documentation-and-book.html
New FreeRTOS e-Book
> The reason why I don't fancy an RTOS is because my
> application needs to run in real time
As in "Real Time" operating system.
> and I expect that an
> RTOS would waste too many resources (time).
This really depends on the application. Sometimes an RTOS is wasteful, but
if when not using pre-emption you are instead polling inputs an RTOS can
free up absolutely masses of processing time. When polling an input the
processor is using lots of cycles when there is nothing to do. If instead
you use an RTOS then processing cycles are only used when there is actually
something that needs to be done.
Of course its not that clear cut and there is more than one way to skin a
cat, and I'm not an advocate of always using an RTOS, but of using the best
tools for the job in hand. Its just interesting some of the comments that
are made.
> (I tested uClinux
> and found that it was not suitable for my application.)
I thought we were talking about RTOS :o)
A lot has to do with the architecture on which the code is running too. For
example, on a Cortex M3 I can get jitter in interrupt timings down to 120ns
(50Mhz clock) - all of which is down to the tail chaining on the processor
short cutting interrupt entry and nothing to do with the RTOS. I took these
measurements when somebody told me they could not possibly use an RTOS for a
motor control app because they needed a jitter of less than 1uS.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for Microcontrollers. More than 7000 downloads per month.
+ www.freertos.org/Documentation/FreeRTOS-documentation-and-book.html
New FreeRTOS e-Book
Reply by ●January 21, 20092009-01-21
Henry,
Do you need the TCP or can you do what you need with just UDP? If so UDP is
something you could put together without OS support. I designed an UDP, IP,
ICMP and ARP system years ago using a state machine running on an AVR. It
took about 3 weeks to do.
Michael Freeman
Update Systems, Inc.
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
h.belig
Sent: Wednesday, January 21, 2009 2:29 PM
To: l...
Subject: [lpc2000] Re: lwIpWeb - no webpage built
Thank you, Chris.
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.
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). (I tested uClinux and found that it was not suitable
for my application.)
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.
You suggest to always use an RTOS and in fact I did not find a sample
without an RTOS (besides lwIpWeb from the files section).
From your experience, would you say that TCP/IP with an RTOS should be
able to run with an application as described above?
Henry
--- In l..., "HM2" wrote:
>
> >> my aim is to get the lwIP-Stack running on EA's LPC2468-16 OEM
board using Rowley's Crosswork.
> >> Can anybody provide sample code with lwIP running under Rowley
but without any RTOS?
>
> I wrote a port for LPC2468 for lwIP-1.30 and FreeRTOS, and it runs.
However lwIP itself has problems. Much more I could say, but trying
to be politically correct I will simply say: I do not recommend lwIP.
I am rewriting NicheLite for GCC right now, and I highly recommend Niche.
>
> As for no RTOS, that is not really practical for any TCP/IP stack.
If you want to do IP, you should expect to use an RTOS. There are
far too many things going on to manage without a task OS. Using an
RTOS is trivial. The TCP/IP stack is where the work is.
>
> Chris.
>
>
>
>
>
>
Do you need the TCP or can you do what you need with just UDP? If so UDP is
something you could put together without OS support. I designed an UDP, IP,
ICMP and ARP system years ago using a state machine running on an AVR. It
took about 3 weeks to do.
Michael Freeman
Update Systems, Inc.
-----Original Message-----
From: l... [mailto:l...]On Behalf Of
h.belig
Sent: Wednesday, January 21, 2009 2:29 PM
To: l...
Subject: [lpc2000] Re: lwIpWeb - no webpage built
Thank you, Chris.
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.
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). (I tested uClinux and found that it was not suitable
for my application.)
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.
You suggest to always use an RTOS and in fact I did not find a sample
without an RTOS (besides lwIpWeb from the files section).
From your experience, would you say that TCP/IP with an RTOS should be
able to run with an application as described above?
Henry
--- In l..., "HM2" wrote:
>
> >> my aim is to get the lwIP-Stack running on EA's LPC2468-16 OEM
board using Rowley's Crosswork.
> >> Can anybody provide sample code with lwIP running under Rowley
but without any RTOS?
>
> I wrote a port for LPC2468 for lwIP-1.30 and FreeRTOS, and it runs.
However lwIP itself has problems. Much more I could say, but trying
to be politically correct I will simply say: I do not recommend lwIP.
I am rewriting NicheLite for GCC right now, and I highly recommend Niche.
>
> As for no RTOS, that is not really practical for any TCP/IP stack.
If you want to do IP, you should expect to use an RTOS. There are
far too many things going on to manage without a task OS. Using an
RTOS is trivial. The TCP/IP stack is where the work is.
>
> Chris.
>
>
>
>
>
>
Reply by ●January 21, 20092009-01-21
> 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.
> 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 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...
http://tech.groups.yahoo.com/group/lpc2000/message/37940
TC
>
> > 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...
http://tech.groups.yahoo.com/group/lpc2000/message/37940
TC
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.
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 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.
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
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.
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.
