hi,
I am using LPC2148 controller interfaced with ENC28J60 (SPI interface) .
I have used TCP/IP stack.
if i use PING command giving the BoardIP Address ,i getcommand output(Showing
LAN connection between host macine and LPC2148).
My concern is ,I have to send data from Windows XP machine to LPC2148.(Such as
if i am sending the data to set LEDs from HOST machine over ethernet,then LEDs
that are present on Embedded board will get glow means controlling of the board
over ethernet), how to achieve it?
Please guide.
Thanks
Nilesh
The INTERNET now has a personality. YOURS! See your Yahoo! Homepage.
http://in.yahoo.com/
ENC28J60 interfaced with LPC2148
Started by ●March 14, 2010
Reply by ●March 14, 20102010-03-14
--- In l..., Nilesh S wrote:
>
> hi,
> I am using LPC2148 controller interfaced with ENC28J60 (SPI interface) .
> I have used TCP/IP stack.
> if i use PING command giving the BoardIP Address ,i getcommand output(Showing LAN connection between host macine and LPC2148).
> My concern is ,I have to send data from Windows XP machine to LPC2148.(Such as if i am sending the data to set LEDs from HOST machine over ethernet,then LEDs that are present on Embedded board will get glow means controlling of the board over ethernet), how to achieve it?
>
> Please guide.
> Thanks
> Nilesh
>
The way this is usually done is to implement and HTTPD server in the '2148. There are a lot of examples of this. The client end sends a HTTP GET request with the data tacked on the request.
uIP has an example of this as does FreeRTOS in ./Demo/uIP_DEMO_Rowley_ARM7
The better way to do it is to just accept a TCP connection at the '2148. I haven't done this but there is a TELNETD in the uIP project.
I have used uIP to make a TCP connection to an HP LaserJet. This allowed an FPGA project to talk to an LPC2106 via SPI where the '2106 took a stream of data, reformatted it, and forwarded it to the printer.
Richard
>
> hi,
> I am using LPC2148 controller interfaced with ENC28J60 (SPI interface) .
> I have used TCP/IP stack.
> if i use PING command giving the BoardIP Address ,i getcommand output(Showing LAN connection between host macine and LPC2148).
> My concern is ,I have to send data from Windows XP machine to LPC2148.(Such as if i am sending the data to set LEDs from HOST machine over ethernet,then LEDs that are present on Embedded board will get glow means controlling of the board over ethernet), how to achieve it?
>
> Please guide.
> Thanks
> Nilesh
>
The way this is usually done is to implement and HTTPD server in the '2148. There are a lot of examples of this. The client end sends a HTTP GET request with the data tacked on the request.
uIP has an example of this as does FreeRTOS in ./Demo/uIP_DEMO_Rowley_ARM7
The better way to do it is to just accept a TCP connection at the '2148. I haven't done this but there is a TELNETD in the uIP project.
I have used uIP to make a TCP connection to an HP LaserJet. This allowed an FPGA project to talk to an LPC2106 via SPI where the '2106 took a stream of data, reformatted it, and forwarded it to the printer.
Richard
Reply by ●March 15, 20102010-03-15
> > I am using LPC2148 controller interfaced with
ENC28J60 (SPI interface) .
> to talk to an LPC2106 via SPI where the '2106 took a stream of data, reformatted it, and forwarded it to the printer.
Hi
Can you explain what the advantage is to use an ENC28J60 together with an LPC2148 or LPC2106?
I am not trying to criticize but rather understand since I may do the same thing, but at the moment just can't find any convincing arguments in its favor:
1) The ENC28J60 has 8k RAM and works only in 10M mode. It requires quite a lot of power (up to 250mA). It costs about $3. Together with an LPC2148 (rather expensive I see at about $9, or the LPC2106 - also rather expensive at about $10) there is a throughput limitation due to the SPI.
2) For about $6 one can use an LPC2364 with internal Ethernet memory and DMA, plus a small external PHY for about $1.50 on top. Faster and lower power with 10/100M Ethernet.
3) Same as 2 for various chips with 32..64k internal SRAM and DMA. (eg. SAM7X for about $7, AVR32 for under $5, M52252 Coldfire for around $5 and a number of others).
4) Or take an 80 or 100pin part with fully integrated 10/100M MAC + PHY:
- Coldfire M52232 for under $6 with 10/100 MAC + PHY, 32k SRAM and DMA.
- Luminary LM3S6965 for under $9 with 64k SRAM, integrated 10/100M MAC + PHY with auto-crossover. Not DMA based, but with 32 bit FIFO it is still fast. In 100M mode its internal EMAC + PHY consumes less that 100mA!!
In particular I am looking at using the LPC2103 together with the ENC28J60. But it does look so limited that it is probably just as well to take a larger part made specially for the job - in terms of board space and final costs there seems very little difference but the restrictions with the ENC28J60 (power consumption, throughput, only 10M) don't make a good impression.
What other factors should be considered?
Regards
Mark
> to talk to an LPC2106 via SPI where the '2106 took a stream of data, reformatted it, and forwarded it to the printer.
Hi
Can you explain what the advantage is to use an ENC28J60 together with an LPC2148 or LPC2106?
I am not trying to criticize but rather understand since I may do the same thing, but at the moment just can't find any convincing arguments in its favor:
1) The ENC28J60 has 8k RAM and works only in 10M mode. It requires quite a lot of power (up to 250mA). It costs about $3. Together with an LPC2148 (rather expensive I see at about $9, or the LPC2106 - also rather expensive at about $10) there is a throughput limitation due to the SPI.
2) For about $6 one can use an LPC2364 with internal Ethernet memory and DMA, plus a small external PHY for about $1.50 on top. Faster and lower power with 10/100M Ethernet.
3) Same as 2 for various chips with 32..64k internal SRAM and DMA. (eg. SAM7X for about $7, AVR32 for under $5, M52252 Coldfire for around $5 and a number of others).
4) Or take an 80 or 100pin part with fully integrated 10/100M MAC + PHY:
- Coldfire M52232 for under $6 with 10/100 MAC + PHY, 32k SRAM and DMA.
- Luminary LM3S6965 for under $9 with 64k SRAM, integrated 10/100M MAC + PHY with auto-crossover. Not DMA based, but with 32 bit FIFO it is still fast. In 100M mode its internal EMAC + PHY consumes less that 100mA!!
In particular I am looking at using the LPC2103 together with the ENC28J60. But it does look so limited that it is probably just as well to take a larger part made specially for the job - in terms of board space and final costs there seems very little difference but the restrictions with the ENC28J60 (power consumption, throughput, only 10M) don't make a good impression.
What other factors should be considered?
Regards
Mark
Reply by ●March 15, 20102010-03-15
All that you point out about the ENC28J60 is probably correct. But you are
overlooking the 'lazy' factor. The device is well known and driver
code is readily available.
Second, when most of the ENC28J60 demo projects were written, the new 'gee whiz' LPCs weren't available. I still don't know if free demo code is available including a complete TCP/IP stack. Maybe one of the lightweight stacks can be used with supplied interface code.
For the commercial developers, none of these issues matter. Component cost is the big deal. They can take the time to write the code.
BTW, the CS8900A is a pretty nice interface as well. It is parallel versus SPI and the drivers are included in the uIP package. But it uses a lot of pins. A competing design issue.
Which brings up the protocol stack. If uIP is selected, it is already limited by 1 packet in transit. It might not make sense to run at 1 GB if you have to wait for the ACK on each packet.
If you want to go fast, move to a FAST chip. Maybe something like the Blackfin. This runs the full Linux system at 500 MHz. Now you have the memory and bandwidth for a full TCP/IP implementation. Expensive...
Richard
--- In l..., "Mark" wrote:
>
> > > I am using LPC2148 controller interfaced with ENC28J60 (SPI interface) .
> > to talk to an LPC2106 via SPI where the '2106 took a stream of data, reformatted it, and forwarded it to the printer.
>
> Hi
>
> Can you explain what the advantage is to use an ENC28J60 together with an LPC2148 or LPC2106?
>
> I am not trying to criticize but rather understand since I may do the same thing, but at the moment just can't find any convincing arguments in its favor:
>
> 1) The ENC28J60 has 8k RAM and works only in 10M mode. It requires quite a lot of power (up to 250mA). It costs about $3. Together with an LPC2148 (rather expensive I see at about $9, or the LPC2106 - also rather expensive at about $10) there is a throughput limitation due to the SPI.
>
> 2) For about $6 one can use an LPC2364 with internal Ethernet memory and DMA, plus a small external PHY for about $1.50 on top. Faster and lower power with 10/100M Ethernet.
>
> 3) Same as 2 for various chips with 32..64k internal SRAM and DMA. (eg. SAM7X for about $7, AVR32 for under $5, M52252 Coldfire for around $5 and a number of others).
>
> 4) Or take an 80 or 100pin part with fully integrated 10/100M MAC + PHY:
> - Coldfire M52232 for under $6 with 10/100 MAC + PHY, 32k SRAM and DMA.
> - Luminary LM3S6965 for under $9 with 64k SRAM, integrated 10/100M MAC + PHY with auto-crossover. Not DMA based, but with 32 bit FIFO it is still fast. In 100M mode its internal EMAC + PHY consumes less that 100mA!!
> In particular I am looking at using the LPC2103 together with the ENC28J60. But it does look so limited that it is probably just as well to take a larger part made specially for the job - in terms of board space and final costs there seems very little difference but the restrictions with the ENC28J60 (power consumption, throughput, only 10M) don't make a good impression.
>
> What other factors should be considered?
>
> Regards
>
> Mark
>
Second, when most of the ENC28J60 demo projects were written, the new 'gee whiz' LPCs weren't available. I still don't know if free demo code is available including a complete TCP/IP stack. Maybe one of the lightweight stacks can be used with supplied interface code.
For the commercial developers, none of these issues matter. Component cost is the big deal. They can take the time to write the code.
BTW, the CS8900A is a pretty nice interface as well. It is parallel versus SPI and the drivers are included in the uIP package. But it uses a lot of pins. A competing design issue.
Which brings up the protocol stack. If uIP is selected, it is already limited by 1 packet in transit. It might not make sense to run at 1 GB if you have to wait for the ACK on each packet.
If you want to go fast, move to a FAST chip. Maybe something like the Blackfin. This runs the full Linux system at 500 MHz. Now you have the memory and bandwidth for a full TCP/IP implementation. Expensive...
Richard
--- In l..., "Mark" wrote:
>
> > > I am using LPC2148 controller interfaced with ENC28J60 (SPI interface) .
> > to talk to an LPC2106 via SPI where the '2106 took a stream of data, reformatted it, and forwarded it to the printer.
>
> Hi
>
> Can you explain what the advantage is to use an ENC28J60 together with an LPC2148 or LPC2106?
>
> I am not trying to criticize but rather understand since I may do the same thing, but at the moment just can't find any convincing arguments in its favor:
>
> 1) The ENC28J60 has 8k RAM and works only in 10M mode. It requires quite a lot of power (up to 250mA). It costs about $3. Together with an LPC2148 (rather expensive I see at about $9, or the LPC2106 - also rather expensive at about $10) there is a throughput limitation due to the SPI.
>
> 2) For about $6 one can use an LPC2364 with internal Ethernet memory and DMA, plus a small external PHY for about $1.50 on top. Faster and lower power with 10/100M Ethernet.
>
> 3) Same as 2 for various chips with 32..64k internal SRAM and DMA. (eg. SAM7X for about $7, AVR32 for under $5, M52252 Coldfire for around $5 and a number of others).
>
> 4) Or take an 80 or 100pin part with fully integrated 10/100M MAC + PHY:
> - Coldfire M52232 for under $6 with 10/100 MAC + PHY, 32k SRAM and DMA.
> - Luminary LM3S6965 for under $9 with 64k SRAM, integrated 10/100M MAC + PHY with auto-crossover. Not DMA based, but with 32 bit FIFO it is still fast. In 100M mode its internal EMAC + PHY consumes less that 100mA!!
> In particular I am looking at using the LPC2103 together with the ENC28J60. But it does look so limited that it is probably just as well to take a larger part made specially for the job - in terms of board space and final costs there seems very little difference but the restrictions with the ENC28J60 (power consumption, throughput, only 10M) don't make a good impression.
>
> What other factors should be considered?
>
> Regards
>
> Mark
>
Reply by ●March 15, 20102010-03-15
--- In l..., "rtstofer" wrote:
>
> when most of the ENC28J60 demo projects were written, the new 'gee whiz' LPCs weren't available.
If I remember correctly the ENC28J60 was announced 2005 and probably became available around 2006. In late 2004 the Freescale MC9S12NE64 became available with 64k FLASH, 8k RAM and an on-board 10/100M EMAC + PHY. 8k RAM was a little limited but for about $6 it was a complete single-chip solution. At one point around the beginning of 2005 I connected an NE64 running TCP/IP stack to an LPC2106 via SPI so that the LPC2106 could either run the TCP/IP stack using the NE64 as an SPI Ethernet controller, or let the NE64 do the stack and just use it as a socket. The LPCs with EMAC only became available later but there have always been other options. (Note that by running the NE64 at 10M, rather than 100M, its power consumption was also a factor 2 less that the announced value of the ENC28J60 - it was however a bit more expensive and bigger).
> Which brings up the protocol stack. If uIP is selected, it is already limited by 1 packet in transit. It might not make sense to run at 1 GB if you have to wait for the ACK on each packet.
The uTasker TCP/IP stack supports buffered TCP and also fast HTTP (using about 60 bytes RAM per socket to achieve windowing). It is also completely free for non-commercial use and has been available since 2005 (originally also with the uIP type limitation).
At the moment the discussion is whether there is any incentive to add ENC28J60 and/or CS8900A driver support to the uTasker project. Personally I still never have seen the incentive to use the ENC28J60 (even to save component costs) from the first day it was announce [if it had arrived a few years earlier it would have been a different matter].
The CS8900A was a very important component some years ago, but today it costs more that a 32 bit processor with fully integrated 10/100M MAC/PHY so again not really relevant when starting a new project.
Again I repeat that I am not trying to pick holes in the use of these because there may be some very good reasons in certain situations. What I am interested in is identifying these cases because I still don't see them myself and may thus be overlooking something important.
Regards
Mark
>
> when most of the ENC28J60 demo projects were written, the new 'gee whiz' LPCs weren't available.
If I remember correctly the ENC28J60 was announced 2005 and probably became available around 2006. In late 2004 the Freescale MC9S12NE64 became available with 64k FLASH, 8k RAM and an on-board 10/100M EMAC + PHY. 8k RAM was a little limited but for about $6 it was a complete single-chip solution. At one point around the beginning of 2005 I connected an NE64 running TCP/IP stack to an LPC2106 via SPI so that the LPC2106 could either run the TCP/IP stack using the NE64 as an SPI Ethernet controller, or let the NE64 do the stack and just use it as a socket. The LPCs with EMAC only became available later but there have always been other options. (Note that by running the NE64 at 10M, rather than 100M, its power consumption was also a factor 2 less that the announced value of the ENC28J60 - it was however a bit more expensive and bigger).
> Which brings up the protocol stack. If uIP is selected, it is already limited by 1 packet in transit. It might not make sense to run at 1 GB if you have to wait for the ACK on each packet.
The uTasker TCP/IP stack supports buffered TCP and also fast HTTP (using about 60 bytes RAM per socket to achieve windowing). It is also completely free for non-commercial use and has been available since 2005 (originally also with the uIP type limitation).
At the moment the discussion is whether there is any incentive to add ENC28J60 and/or CS8900A driver support to the uTasker project. Personally I still never have seen the incentive to use the ENC28J60 (even to save component costs) from the first day it was announce [if it had arrived a few years earlier it would have been a different matter].
The CS8900A was a very important component some years ago, but today it costs more that a 32 bit processor with fully integrated 10/100M MAC/PHY so again not really relevant when starting a new project.
Again I repeat that I am not trying to pick holes in the use of these because there may be some very good reasons in certain situations. What I am interested in is identifying these cases because I still don't see them myself and may thus be overlooking something important.
Regards
Mark
Reply by ●March 15, 20102010-03-15
--- In l..., "Mark" wrote:
> At the moment the discussion is whether there is any incentive to add ENC28J60 and/or CS8900A driver support to the uTasker project. Personally I still never have seen the incentive to use the ENC28J60 (even to save component costs) from the first day it was announce [if it had arrived a few years earlier it would have been a different matter].
There is probably no reason unless a customer inquires. As this is really a forum about LPC2000 devices and these didn't have Ethernet capability when originally offered, the ENC28J60 probably was important - back then.
I haven't looked but unless I could get free demo code for the ethernet interface in the newer LPCs, they still wouldn't be interesting. But this is from a hobbyist's point of view. Chip cost is not an issue. The time it takes to write code is.
Even the eZ80 now has an internal ethernet gadget. And the chip just screams at 60 MHz (sort of) but I have to BUY the TCP/IP stack. Yes, I used the device to build a retro CP/M system but I didn't use the network interface and never will. If I wanted networking, I would probably still use the CS8900A because the stack exists and it is FREE.
>
> The CS8900A was a very important component some years ago, but today it costs more that a 32 bit processor with fully integrated 10/100M MAC/PHY so again not really relevant when starting a new project.
Again, it was an important device a while back. Heck I used it on a project last year. The fact that drivers are included with uIP just about dictated the choice. From my VERY LIMITED point of view, free code is more important than chip elegance.
>
> Again I repeat that I am not trying to pick holes in the use of these because there may be some very good reasons in certain situations. What I am interested in is identifying these cases because I still don't see them myself and may thus be overlooking something important.
From what I recall of the driver code, it really only provides a couple of functions: send packet, receive packet and get status. It certainly wouldn't be any serious effort to add a driver to uTasker. If anybody ever asks for it...
Time moves on and chip capabilities change. Using the ENC28J60 might not be as important today.
Richard
> At the moment the discussion is whether there is any incentive to add ENC28J60 and/or CS8900A driver support to the uTasker project. Personally I still never have seen the incentive to use the ENC28J60 (even to save component costs) from the first day it was announce [if it had arrived a few years earlier it would have been a different matter].
There is probably no reason unless a customer inquires. As this is really a forum about LPC2000 devices and these didn't have Ethernet capability when originally offered, the ENC28J60 probably was important - back then.
I haven't looked but unless I could get free demo code for the ethernet interface in the newer LPCs, they still wouldn't be interesting. But this is from a hobbyist's point of view. Chip cost is not an issue. The time it takes to write code is.
Even the eZ80 now has an internal ethernet gadget. And the chip just screams at 60 MHz (sort of) but I have to BUY the TCP/IP stack. Yes, I used the device to build a retro CP/M system but I didn't use the network interface and never will. If I wanted networking, I would probably still use the CS8900A because the stack exists and it is FREE.
>
> The CS8900A was a very important component some years ago, but today it costs more that a 32 bit processor with fully integrated 10/100M MAC/PHY so again not really relevant when starting a new project.
Again, it was an important device a while back. Heck I used it on a project last year. The fact that drivers are included with uIP just about dictated the choice. From my VERY LIMITED point of view, free code is more important than chip elegance.
>
> Again I repeat that I am not trying to pick holes in the use of these because there may be some very good reasons in certain situations. What I am interested in is identifying these cases because I still don't see them myself and may thus be overlooking something important.
From what I recall of the driver code, it really only provides a couple of functions: send packet, receive packet and get status. It certainly wouldn't be any serious effort to add a driver to uTasker. If anybody ever asks for it...
Time moves on and chip capabilities change. Using the ENC28J60 might not be as important today.
Richard
Reply by ●March 15, 20102010-03-15
Have you looked at the Wiznet w5100 or w5300. If you're going to use
an external device, might as well use one that handles all the
functions without processor overhead.
DaveS
On Mon, Mar 15, 2010 at 8:45 AM, rtstofer wrote:
> --- In l..., "Mark" wrote:
>
>> At the moment the discussion is whether there is any incentive to add ENC28J60 and/or CS8900A driver support to the uTasker project. Personally I still never have seen the incentive to use the ENC28J60 (even to save component costs) from the first day it was announce [if it had arrived a few years earlier it would have been a different matter].
>
> There is probably no reason unless a customer inquires. As this is really a forum about LPC2000 devices and these didn't have Ethernet capability when originally offered, the ENC28J60 probably was important - back then.
>
> I haven't looked but unless I could get free demo code for the ethernet interface in the newer LPCs, they still wouldn't be interesting. But this is from a hobbyist's point of view. Chip cost is not an issue. The time it takes to write code is.
>
> Even the eZ80 now has an internal ethernet gadget. And the chip just screams at 60 MHz (sort of) but I have to BUY the TCP/IP stack. Yes, I used the device to build a retro CP/M system but I didn't use the network interface and never will. If I wanted networking, I would probably still use the CS8900A because the stack exists and it is FREE.
>>
>> The CS8900A was a very important component some years ago, but today it costs more that a 32 bit processor with fully integrated 10/100M MAC/PHY so again not really relevant when starting a new project.
> Again, it was an important device a while back. Heck I used it on a project last year. The fact that drivers are included with uIP just about dictated the choice. From my VERY LIMITED point of view, free code is more important than chip elegance.
>>
>> Again I repeat that I am not trying to pick holes in the use of these because there may be some very good reasons in certain situations. What I am interested in is identifying these cases because I still don't see them myself and may thus be overlooking something important.
> From what I recall of the driver code, it really only provides a couple of functions: send packet, receive packet and get status. It certainly wouldn't be any serious effort to add a driver to uTasker. If anybody ever asks for it...
>
> Time moves on and chip capabilities change. Using the ENC28J60 might not be as important today.
>
> Richard
>
an external device, might as well use one that handles all the
functions without processor overhead.
DaveS
On Mon, Mar 15, 2010 at 8:45 AM, rtstofer wrote:
> --- In l..., "Mark" wrote:
>
>> At the moment the discussion is whether there is any incentive to add ENC28J60 and/or CS8900A driver support to the uTasker project. Personally I still never have seen the incentive to use the ENC28J60 (even to save component costs) from the first day it was announce [if it had arrived a few years earlier it would have been a different matter].
>
> There is probably no reason unless a customer inquires. As this is really a forum about LPC2000 devices and these didn't have Ethernet capability when originally offered, the ENC28J60 probably was important - back then.
>
> I haven't looked but unless I could get free demo code for the ethernet interface in the newer LPCs, they still wouldn't be interesting. But this is from a hobbyist's point of view. Chip cost is not an issue. The time it takes to write code is.
>
> Even the eZ80 now has an internal ethernet gadget. And the chip just screams at 60 MHz (sort of) but I have to BUY the TCP/IP stack. Yes, I used the device to build a retro CP/M system but I didn't use the network interface and never will. If I wanted networking, I would probably still use the CS8900A because the stack exists and it is FREE.
>>
>> The CS8900A was a very important component some years ago, but today it costs more that a 32 bit processor with fully integrated 10/100M MAC/PHY so again not really relevant when starting a new project.
> Again, it was an important device a while back. Heck I used it on a project last year. The fact that drivers are included with uIP just about dictated the choice. From my VERY LIMITED point of view, free code is more important than chip elegance.
>>
>> Again I repeat that I am not trying to pick holes in the use of these because there may be some very good reasons in certain situations. What I am interested in is identifying these cases because I still don't see them myself and may thus be overlooking something important.
> From what I recall of the driver code, it really only provides a couple of functions: send packet, receive packet and get status. It certainly wouldn't be any serious effort to add a driver to uTasker. If anybody ever asks for it...
>
> Time moves on and chip capabilities change. Using the ENC28J60 might not be as important today.
>
> Richard
>
