The AT91SAM7X may not be available yet. I don't see stock at digikey,
and
on the Atmel site there is no "buy from distribution" link like there
is
for other full production chips like the regular SAM7. Quite a few AT91
chips look interesting, if you can get your hands on them ....
-- Doug
>Have you looked at the Atmel AT91SAM7X?
>
LPC's w/ ENC28J60 for ethernet via SPI
Started by ●January 5, 2006
Reply by ●January 5, 20062006-01-05
Reply by ●January 5, 20062006-01-05
> The AT91SAM7X may not be available yet. I don't see stock at
digikey, and
> on the Atmel site there is no "buy from distribution" link like there is
> for other full production chips like the regular SAM7. Quite a few AT91
> chips look interesting, if you can get your hands on them ....
I received two samples from All American over two months ago. No posted
errata so either silicon revision, or queued for fab.
Joel
> on the Atmel site there is no "buy from distribution" link like there is
> for other full production chips like the regular SAM7. Quite a few AT91
> chips look interesting, if you can get your hands on them ....
I received two samples from All American over two months ago. No posted
errata so either silicon revision, or queued for fab.
Joel
Reply by ●January 5, 20062006-01-05
Hi Adrian,
Oh hey, good call! I'm not sure why I missed this solution. I think
it's because I was erroneously remembering the max clock input to the
LPC2292 as 20MHz rather than the correct 25MHz with PLL or 30MHz
without. Thanks for pointing out what should have been obvious!
-Ryan --- In lpc2000@lpc2..., delta soft <rfidro@y...> wrote:
>
> Hello,
>
> You can use the 25MHZ clk from ENC28J60 to drive the
> LPC. In this case, you will "use the same clock
> source for both ENC28J60 and the host controller..."
>
> For LPC2292 you can have 25 or 50MHZ.
>
> Adrian
>
> Adrian Valeanu.
> SC PROSAFE SRL
> J/40/11835/2002 ; CUI 15026939
> Aleea Politehnicii nr. 2
> Bl. 5A, sc. 1 Ap. 17 Sector 6, BUCHAREST
> ROMANIA
> Tel/fax +40 (21) 781.38.58
Oh hey, good call! I'm not sure why I missed this solution. I think
it's because I was erroneously remembering the max clock input to the
LPC2292 as 20MHz rather than the correct 25MHz with PLL or 30MHz
without. Thanks for pointing out what should have been obvious!
-Ryan --- In lpc2000@lpc2..., delta soft <rfidro@y...> wrote:
>
> Hello,
>
> You can use the 25MHZ clk from ENC28J60 to drive the
> LPC. In this case, you will "use the same clock
> source for both ENC28J60 and the host controller..."
>
> For LPC2292 you can have 25 or 50MHZ.
>
> Adrian
>
> Adrian Valeanu.
> SC PROSAFE SRL
> J/40/11835/2002 ; CUI 15026939
> Aleea Politehnicii nr. 2
> Bl. 5A, sc. 1 Ap. 17 Sector 6, BUCHAREST
> ROMANIA
> Tel/fax +40 (21) 781.38.58
Reply by ●January 5, 20062006-01-05
Hi,
Several time ago I was asking the same question here. Look at the "
TCP/IP stack + RTOS for LPC213x ?" topic.
It appears the ENC28J60 device has some issues with power consumption.
Also my local distributer said there are some other issues with this
device, but this is unofficial. My advice would be to double check this.
I have some bad experiences with buggy devices resulting in big project
delays.
In few weeks I will also start a design with ethernet connection and for
sure I will choose a well tested device like RTL8019A or CS8900A is.
It was just my IMHO....
regards,
marko
Ryan Niemi wrote:
>Hello,
>
>I'm working on a project that'll require ethernet. I was hoping the
>LPC's w/ onboard MAC/PHY would come out before this project had to
>start, but alas, no such luck! I've done the CS8900A, RTL8019A and
>Asix 10/100 routes before on past projects, but this application needs
>to be minimal space and lowest netlist connection count as possible to
>route in a minimally sized PCB. Ethernet performance requirements
>isn't high, it'll just be some signalling and status packets to a
>control app over UDP.
>
>Has anyone interfaced a Microchip ENC28J60 MAC/PHY to an LPC via SPI?
> While looking at it, I ran across a potential problem. The LPC2292
>datasheet section on the SPI interfaces say the SPI clock has a
>maximum of 1/8 the input clock. The ENC28J60 errata says reading or
>writing the MAC registers may be unreliable if the SPI clock is below
>8MHz. At 60MHz, it would appear the max LPC SPI clock is 7.5MHz. I'm
>contemplating overclocking the LPC slightly by using a 16MHz clock
>scaled to 64MHz, which would allow an 8MHz SPI clock. But before I
>spend a bunch of time and money (it's a semi-personal project just for
>fun) to try it, I figured I'd check if anyone has blazed this trail
>before..
>
>Alternatives were Cirrus EP9301/2, but the package is large and I
>still need an external PHY anyway. Atmel AT91RM9200 borders on cost
>sensitivity and also requires external PHY. Not to mention external
>flash and RAM. So I'm stuck with two chips minimum anyway, so might
>as well try to go with the LPC2292 as the most suitable CPU choice and
>select an ethernet solution around it.
>
>-Ryan >
>Yahoo! Groups Links >
Several time ago I was asking the same question here. Look at the "
TCP/IP stack + RTOS for LPC213x ?" topic.
It appears the ENC28J60 device has some issues with power consumption.
Also my local distributer said there are some other issues with this
device, but this is unofficial. My advice would be to double check this.
I have some bad experiences with buggy devices resulting in big project
delays.
In few weeks I will also start a design with ethernet connection and for
sure I will choose a well tested device like RTL8019A or CS8900A is.
It was just my IMHO....
regards,
marko
Ryan Niemi wrote:
>Hello,
>
>I'm working on a project that'll require ethernet. I was hoping the
>LPC's w/ onboard MAC/PHY would come out before this project had to
>start, but alas, no such luck! I've done the CS8900A, RTL8019A and
>Asix 10/100 routes before on past projects, but this application needs
>to be minimal space and lowest netlist connection count as possible to
>route in a minimally sized PCB. Ethernet performance requirements
>isn't high, it'll just be some signalling and status packets to a
>control app over UDP.
>
>Has anyone interfaced a Microchip ENC28J60 MAC/PHY to an LPC via SPI?
> While looking at it, I ran across a potential problem. The LPC2292
>datasheet section on the SPI interfaces say the SPI clock has a
>maximum of 1/8 the input clock. The ENC28J60 errata says reading or
>writing the MAC registers may be unreliable if the SPI clock is below
>8MHz. At 60MHz, it would appear the max LPC SPI clock is 7.5MHz. I'm
>contemplating overclocking the LPC slightly by using a 16MHz clock
>scaled to 64MHz, which would allow an 8MHz SPI clock. But before I
>spend a bunch of time and money (it's a semi-personal project just for
>fun) to try it, I figured I'd check if anyone has blazed this trail
>before..
>
>Alternatives were Cirrus EP9301/2, but the package is large and I
>still need an external PHY anyway. Atmel AT91RM9200 borders on cost
>sensitivity and also requires external PHY. Not to mention external
>flash and RAM. So I'm stuck with two chips minimum anyway, so might
>as well try to go with the LPC2292 as the most suitable CPU choice and
>select an ethernet solution around it.
>
>-Ryan >
>Yahoo! Groups Links >
Reply by ●January 5, 20062006-01-05
Marko Panger wrote:
> Hi,
>
> Several time ago I was asking the same question here. Look at the "
> TCP/IP stack + RTOS for LPC213x ?" topic.
>
> It appears the ENC28J60 device has some issues with power consumption.
> Also my local distributer said there are some other issues with this
> device, but this is unofficial. My advice would be to double check this.
> I have some bad experiences with buggy devices resulting in big project
> delays.
>
> In few weeks I will also start a design with ethernet connection and for
> sure I will choose a well tested device like RTL8019A or CS8900A is.
>
> It was just my IMHO....
>
> regards,
> marko
>
Marko, I had similar discussion with your local distributor ;) (over a
beer or two)....
ok, I am sure microchip is doing good job here, but I have some doubts
and major one is:
Operating Current 250 mA ??? why do they need quarter Amp?
> Hi,
>
> Several time ago I was asking the same question here. Look at the "
> TCP/IP stack + RTOS for LPC213x ?" topic.
>
> It appears the ENC28J60 device has some issues with power consumption.
> Also my local distributer said there are some other issues with this
> device, but this is unofficial. My advice would be to double check this.
> I have some bad experiences with buggy devices resulting in big project
> delays.
>
> In few weeks I will also start a design with ethernet connection and for
> sure I will choose a well tested device like RTL8019A or CS8900A is.
>
> It was just my IMHO....
>
> regards,
> marko
>
Marko, I had similar discussion with your local distributor ;) (over a
beer or two)....
ok, I am sure microchip is doing good job here, but I have some doubts
and major one is:
Operating Current 250 mA ??? why do they need quarter Amp?
Reply by ●January 6, 20062006-01-06
> ok, I am sure microchip is doing good job here, but I have some
doubts
> and major one is:
> Operating Current 250 mA ??? why do they need quarter Amp?
>
Hi all
I have been watching the ENC28J60 for over a year now. Originally
samples were promised for Feb. 2005 but never arrived. In the mentime
have done a number of embedded Internet projects using the MC9S12NE64
(HCS12 with embedded 10/100 LAN MAC + PHY) - a good solution for space
sensitive devices when the relatively low resources can be tolerated -
however using a good compiler you can still pack a lot of
functionality in to it! Some interactive demos are at www.mjbc.ch.
Am now starting with AT91SAM7x (shame that it needs external PHY)
which is a good step up in terms of performance and resources.
Hopefully the Philips ARM equivalent will be available soon, and then
the new Coldfire (a serious competitor in this segment) is high on
the "to do" list.
As for the ENC28J60: When I saw the 250mA current consumption at 10M
(if it is really true) my jaw also dropped. A standard CS8900A needs
maximum 20% of this and a complete NE64 board running with 10M
Ethernet requires only 100mA, including the processor at 50MHz: at
100M the current consumption doubles.
I did also some tests with an LPC2106 using the NE64 as an Ethernet
coprocessor via SPI, which is also an interesting possibility when
more processing power is required - the NE64 can also handle the
TCP/IP stack and leave the LPC2106 to concentrate on its main tasks.
What is however a bit of a let down is the fact that the LPC2106
doesnt support DMA on the SPI interface and this can severely
restrict the throughput - I concluded that this would also be a
shortcoming if using the ENC28J60 with the LPC2106 (or equivalent).
My conclusions are:
- the ENC28J60 is an interesting device but until it is known to be
stable and is optimised to have a sensible current consumption
(possibly also 100M operation) I prefer the NE64 coprocessor solution
via SPI.
- due to the lack of DMA support on the SPI, the SPI solution is not
considered ideal with the LPC2106 (or equivalents).
- with the planned introduction of the Philips ARM device with 10/100M
LAN it is probably better to wait a little longer for this
- Today I prefer the AT91SAM7x for mid-range embedded Internet
applications (although I havent used the device much yet and may
still have a suprise or two).
- For low-range embedded Internet applications the MC9S12NE64 is king.
PCB design is extremely simple and a double layer board works fine,
even when using all peripherals - see some photos at
http://www.mjbc.ch/pics/uTasker/uTasker1_eng.html (if only SPI/LAN is
required, it can almost fit under a standard RJ45 connector).
Regards
Mark Butcher
www.mjbc.ch
doubts
> and major one is:
> Operating Current 250 mA ??? why do they need quarter Amp?
>
Hi all
I have been watching the ENC28J60 for over a year now. Originally
samples were promised for Feb. 2005 but never arrived. In the mentime
have done a number of embedded Internet projects using the MC9S12NE64
(HCS12 with embedded 10/100 LAN MAC + PHY) - a good solution for space
sensitive devices when the relatively low resources can be tolerated -
however using a good compiler you can still pack a lot of
functionality in to it! Some interactive demos are at www.mjbc.ch.
Am now starting with AT91SAM7x (shame that it needs external PHY)
which is a good step up in terms of performance and resources.
Hopefully the Philips ARM equivalent will be available soon, and then
the new Coldfire (a serious competitor in this segment) is high on
the "to do" list.
As for the ENC28J60: When I saw the 250mA current consumption at 10M
(if it is really true) my jaw also dropped. A standard CS8900A needs
maximum 20% of this and a complete NE64 board running with 10M
Ethernet requires only 100mA, including the processor at 50MHz: at
100M the current consumption doubles.
I did also some tests with an LPC2106 using the NE64 as an Ethernet
coprocessor via SPI, which is also an interesting possibility when
more processing power is required - the NE64 can also handle the
TCP/IP stack and leave the LPC2106 to concentrate on its main tasks.
What is however a bit of a let down is the fact that the LPC2106
doesnt support DMA on the SPI interface and this can severely
restrict the throughput - I concluded that this would also be a
shortcoming if using the ENC28J60 with the LPC2106 (or equivalent).
My conclusions are:
- the ENC28J60 is an interesting device but until it is known to be
stable and is optimised to have a sensible current consumption
(possibly also 100M operation) I prefer the NE64 coprocessor solution
via SPI.
- due to the lack of DMA support on the SPI, the SPI solution is not
considered ideal with the LPC2106 (or equivalents).
- with the planned introduction of the Philips ARM device with 10/100M
LAN it is probably better to wait a little longer for this
- Today I prefer the AT91SAM7x for mid-range embedded Internet
applications (although I havent used the device much yet and may
still have a suprise or two).
- For low-range embedded Internet applications the MC9S12NE64 is king.
PCB design is extremely simple and a double layer board works fine,
even when using all peripherals - see some photos at
http://www.mjbc.ch/pics/uTasker/uTasker1_eng.html (if only SPI/LAN is
required, it can almost fit under a standard RJ45 connector).
Regards
Mark Butcher
www.mjbc.ch
Reply by ●January 6, 20062006-01-06
Hello Mark,
> - For low-range embedded Internet applications the MC9S12NE64 is king.
> PCB design is extremely simple and a double layer board works fine,
> even when using all peripherals - see some photos at
> http://www.mjbc.ch/pics/uTasker/uTasker1_eng.html (if only SPI/LAN is
> required, it can almost fit under a standard RJ45 connector)
I've experienced networks that brought high powered Coldfire based solutions
to their knees due to level of ARP traffic. How does the MC9S12NE64 respond
with abnormally high ARP traffic?
On the upcoming LPC Ethernet solution I really hope they spend some extra
effort on Ethernet hardware filtering and IP hardware checksum via DMA.
Joel
> - For low-range embedded Internet applications the MC9S12NE64 is king.
> PCB design is extremely simple and a double layer board works fine,
> even when using all peripherals - see some photos at
> http://www.mjbc.ch/pics/uTasker/uTasker1_eng.html (if only SPI/LAN is
> required, it can almost fit under a standard RJ45 connector)
I've experienced networks that brought high powered Coldfire based solutions
to their knees due to level of ARP traffic. How does the MC9S12NE64 respond
with abnormally high ARP traffic?
On the upcoming LPC Ethernet solution I really hope they spend some extra
effort on Ethernet hardware filtering and IP hardware checksum via DMA.
Joel
Reply by ●January 7, 20062006-01-07
Hi Joel
I havent experienced this problem but if a powerful Coldfire gets
overloaded then the NE64 will certainly also have problems.
It is possible to specifically block ARP frames in the hardware
filter so that they dont disturb but this would mean that other
devices on the network wouldnt be able to find the NE64 since it
would not be able to react to ARP requests. If this can be
tolerated, the filer could be deactivated for the time the NE64 is
resolving local addresses, but it makes for a very special solution
rather than a general one.
Arp frames themselves are not very demanding since most can be
ignored if the IP address is is not equal to the local one (although
a local ARP table is generally maintained which includes all network
activity seen).
I have always understood that general broadcast frames cause most
overloading problems and it also certainly helps to not operate in
promiscuous mode on a network with high foreign activity levels.
Using switches to shield weaker devices can also help.
However at the end of the day there are real limits. If frames have
to be handled, this requires time and if the frame rate is faster
than the throughput then something will inevitably get lost. If a
100M LAN is really operating at the limit, each byte should be
processed in about 80ns and that requires a certain level of power.
It is difficult to say where the limit for a particular application
in a particular network lies but it doesnt make much sense to
connect a NE64 in promiscuous mode next to a Cisco router - probably
neither a Coldfire. For many other jobs they are nevertheless fine.
Cheers
Mark
www.mjbc.ch --- In lpc2000@lpc2..., "Joel Winarske" <joelw@i...> wrote:
>
> Hello Mark,
>
> > - For low-range embedded Internet applications the MC9S12NE64 is
king.
> > PCB design is extremely simple and a double layer board works
fine,
> > even when using all peripherals - see some photos at
> > http://www.mjbc.ch/pics/uTasker/uTasker1_eng.html (if only
SPI/LAN is
> > required, it can almost fit under a standard RJ45 connector)
>
> I've experienced networks that brought high powered Coldfire based
solutions
> to their knees due to level of ARP traffic. How does the
MC9S12NE64 respond
> with abnormally high ARP traffic?
>
> On the upcoming LPC Ethernet solution I really hope they spend
some extra
> effort on Ethernet hardware filtering and IP hardware checksum via
DMA.
>
> Joel
>
I havent experienced this problem but if a powerful Coldfire gets
overloaded then the NE64 will certainly also have problems.
It is possible to specifically block ARP frames in the hardware
filter so that they dont disturb but this would mean that other
devices on the network wouldnt be able to find the NE64 since it
would not be able to react to ARP requests. If this can be
tolerated, the filer could be deactivated for the time the NE64 is
resolving local addresses, but it makes for a very special solution
rather than a general one.
Arp frames themselves are not very demanding since most can be
ignored if the IP address is is not equal to the local one (although
a local ARP table is generally maintained which includes all network
activity seen).
I have always understood that general broadcast frames cause most
overloading problems and it also certainly helps to not operate in
promiscuous mode on a network with high foreign activity levels.
Using switches to shield weaker devices can also help.
However at the end of the day there are real limits. If frames have
to be handled, this requires time and if the frame rate is faster
than the throughput then something will inevitably get lost. If a
100M LAN is really operating at the limit, each byte should be
processed in about 80ns and that requires a certain level of power.
It is difficult to say where the limit for a particular application
in a particular network lies but it doesnt make much sense to
connect a NE64 in promiscuous mode next to a Cisco router - probably
neither a Coldfire. For many other jobs they are nevertheless fine.
Cheers
Mark
www.mjbc.ch --- In lpc2000@lpc2..., "Joel Winarske" <joelw@i...> wrote:
>
> Hello Mark,
>
> > - For low-range embedded Internet applications the MC9S12NE64 is
king.
> > PCB design is extremely simple and a double layer board works
fine,
> > even when using all peripherals - see some photos at
> > http://www.mjbc.ch/pics/uTasker/uTasker1_eng.html (if only
SPI/LAN is
> > required, it can almost fit under a standard RJ45 connector)
>
> I've experienced networks that brought high powered Coldfire based
solutions
> to their knees due to level of ARP traffic. How does the
MC9S12NE64 respond
> with abnormally high ARP traffic?
>
> On the upcoming LPC Ethernet solution I really hope they spend
some extra
> effort on Ethernet hardware filtering and IP hardware checksum via
DMA.
>
> Joel
>
Reply by ●January 8, 20062006-01-08
> Have you looked at the Atmel AT91SAM7X?
I took a brief look, but availability concerns me. Actually, while
getting into an alternate CPU discussion, I came up with an
interesting silicon cost comparison for some of my options. These
prices below are based on single unit quantities priced via Digikey:
LPC2292 $13.46
CS8900A $8.36
256Kx16 SRAM $4.41 Total: $26.23
EP9302 $16.14
64Mb (4Mx16) SDRAM $5.67
Micrel 10/100 PHY $3.78
4Mb (512KB) SPI flash $2.15 Total: $27.74
Hmm, $26.23 for an ARM7TDMI @ 60MHz, 256KB flash, 512KB SRAM, 10mbps
ethernet, vs. $27.74 for an ARM920T @ 200MHz, 512KB flash, 8MB SDRAM,
10/100 ethernet. A whole $1.51 additional silicon cost.
Granted however that the EP9302 solution takes up more board space,
requires somewhat more complicated code to bring up the chip w/ cache
and MMU config, and there's a lot more core power decoupling
requirements (possibly necesitating going to 4 layers vs. 2 w/ the
LPC). I've been down the EP9301/2 route before, and I'll admit that
designing and bringing up an ARM920T microprocessor design *is* quite
a bit more complex than the LPC microcontrollers.. On the otherhand,
it can run eCos or Linux (if some more flash is added) with the Cirrus
board support package nearly out-of-the-box..
That bugs me that a full ARM920T ethernet solution comes that close to
cost to the ARM7TDMI LPC's. Its things like that which make our lives
difficult in selecting chips! Now if the ethernet LPC's w/ onboard
PHY's were on the scene in some reasonable timeframe, it would be a
no-brainer..
For anyone confused on my SPI flash choice above in the comparison,
the reason is that the Cirrus ARM920T's (and Atmel ARM920T if I recall
correctly) will happily boot off a SPI flash. Minimal pin and netlist
count for the flash interfacing (board routing mayhem, especially when
you have SDRAM on the bus too!), then I whip up a simple bootloader
that loads the firmware from serial flash to SDRAM. I usually
compress the serial flash image with an LZO variant and decompress in
the small bootloader program while loading to SDRAM.
-Ryan --- In lpc2000@lpc2..., "Joel Winarske" <joelw@i...> wrote:
>
> > Alternatives were Cirrus EP9301/2, but the package is large and I
> > still need an external PHY anyway. Atmel AT91RM9200 borders on cost
> > sensitivity and also requires external PHY. Not to mention external
> > flash and RAM. So I'm stuck with two chips minimum anyway, so might
> > as well try to go with the LPC2292 as the most suitable CPU choice and
> > select an ethernet solution around it.
>
> Have you looked at the Atmel AT91SAM7X?
>
http://www.at91.com/Pages/products/microcontroller/AT91SAM/AT91SAM7X/at91sam
> 7x.html
>
> Joel
>
I took a brief look, but availability concerns me. Actually, while
getting into an alternate CPU discussion, I came up with an
interesting silicon cost comparison for some of my options. These
prices below are based on single unit quantities priced via Digikey:
LPC2292 $13.46
CS8900A $8.36
256Kx16 SRAM $4.41 Total: $26.23
EP9302 $16.14
64Mb (4Mx16) SDRAM $5.67
Micrel 10/100 PHY $3.78
4Mb (512KB) SPI flash $2.15 Total: $27.74
Hmm, $26.23 for an ARM7TDMI @ 60MHz, 256KB flash, 512KB SRAM, 10mbps
ethernet, vs. $27.74 for an ARM920T @ 200MHz, 512KB flash, 8MB SDRAM,
10/100 ethernet. A whole $1.51 additional silicon cost.
Granted however that the EP9302 solution takes up more board space,
requires somewhat more complicated code to bring up the chip w/ cache
and MMU config, and there's a lot more core power decoupling
requirements (possibly necesitating going to 4 layers vs. 2 w/ the
LPC). I've been down the EP9301/2 route before, and I'll admit that
designing and bringing up an ARM920T microprocessor design *is* quite
a bit more complex than the LPC microcontrollers.. On the otherhand,
it can run eCos or Linux (if some more flash is added) with the Cirrus
board support package nearly out-of-the-box..
That bugs me that a full ARM920T ethernet solution comes that close to
cost to the ARM7TDMI LPC's. Its things like that which make our lives
difficult in selecting chips! Now if the ethernet LPC's w/ onboard
PHY's were on the scene in some reasonable timeframe, it would be a
no-brainer..
For anyone confused on my SPI flash choice above in the comparison,
the reason is that the Cirrus ARM920T's (and Atmel ARM920T if I recall
correctly) will happily boot off a SPI flash. Minimal pin and netlist
count for the flash interfacing (board routing mayhem, especially when
you have SDRAM on the bus too!), then I whip up a simple bootloader
that loads the firmware from serial flash to SDRAM. I usually
compress the serial flash image with an LZO variant and decompress in
the small bootloader program while loading to SDRAM.
-Ryan --- In lpc2000@lpc2..., "Joel Winarske" <joelw@i...> wrote:
>
> > Alternatives were Cirrus EP9301/2, but the package is large and I
> > still need an external PHY anyway. Atmel AT91RM9200 borders on cost
> > sensitivity and also requires external PHY. Not to mention external
> > flash and RAM. So I'm stuck with two chips minimum anyway, so might
> > as well try to go with the LPC2292 as the most suitable CPU choice and
> > select an ethernet solution around it.
>
> Have you looked at the Atmel AT91SAM7X?
>
http://www.at91.com/Pages/products/microcontroller/AT91SAM/AT91SAM7X/at91sam
> 7x.html
>
> Joel
>
Reply by ●January 8, 20062006-01-08
Ryan Niemi wrote:
>>Have you looked at the Atmel AT91SAM7X?
>>
>>
>
>I took a brief look, but availability concerns me. Actually, while
>getting into an alternate CPU discussion, I came up with an
>interesting silicon cost comparison for some of my options. These
>prices below are based on single unit quantities priced via Digikey:
>
>LPC2292 $13.46
>CS8900A $8.36
>256Kx16 SRAM $4.41 Total: $26.23
>
>EP9302 $16.14
>64Mb (4Mx16) SDRAM $5.67
>Micrel 10/100 PHY $3.78
>4Mb (512KB) SPI flash $2.15 Total: $27.74
>
>Hmm, $26.23 for an ARM7TDMI @ 60MHz, 256KB flash, 512KB SRAM, 10mbps
>ethernet, vs. $27.74 for an ARM920T @ 200MHz, 512KB flash, 8MB SDRAM,
>10/100 ethernet. A whole $1.51 additional silicon cost.
Then take the EP9302 and add:
Previous cost: $27.74
SD Socket: $3.80
SD 128Meg card: $8.00
64Mb (4Mx16) SDRAM -$5.67
32MByte (16Mx16) SDRAM $12.54 Total: $46.41
And you get a killer Linux powered embedded system!
BTW, where did you find the cost of the EP9302? I cannot seem to find
anyone but Cirrus that you can get those parts from (e.g. Nu-Horizons,
etc.).
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------
>>Have you looked at the Atmel AT91SAM7X?
>>
>>
>
>I took a brief look, but availability concerns me. Actually, while
>getting into an alternate CPU discussion, I came up with an
>interesting silicon cost comparison for some of my options. These
>prices below are based on single unit quantities priced via Digikey:
>
>LPC2292 $13.46
>CS8900A $8.36
>256Kx16 SRAM $4.41 Total: $26.23
>
>EP9302 $16.14
>64Mb (4Mx16) SDRAM $5.67
>Micrel 10/100 PHY $3.78
>4Mb (512KB) SPI flash $2.15 Total: $27.74
>
>Hmm, $26.23 for an ARM7TDMI @ 60MHz, 256KB flash, 512KB SRAM, 10mbps
>ethernet, vs. $27.74 for an ARM920T @ 200MHz, 512KB flash, 8MB SDRAM,
>10/100 ethernet. A whole $1.51 additional silicon cost.
Then take the EP9302 and add:
Previous cost: $27.74
SD Socket: $3.80
SD 128Meg card: $8.00
64Mb (4Mx16) SDRAM -$5.67
32MByte (16Mx16) SDRAM $12.54 Total: $46.41
And you get a killer Linux powered embedded system!
BTW, where did you find the cost of the EP9302? I cannot seem to find
anyone but Cirrus that you can get those parts from (e.g. Nu-Horizons,
etc.).
Regards,
TomW
--
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------