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
>
> 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 Mark●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
Reply by rtstofer●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
>
Reply by Mark●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
Reply by rtstofer●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
Reply by Nilesh S●March 14, 20102010-03-14
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/