arm7 atmel vs others - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: arm7 atmel vs others
snipped-for-privacy@pyy.embedtronics.fi says...
Quoted text here. Click to load it

I guess that's why I always like to have a few extra GPIO pins.  Just
run the same signal to the CAPture pin and a different pin to read the
level.  Then  there's no need to reconfigure the capture pin and
you shouldn't miss any events that happen within the capture timing
limits.


Quoted text here. Click to load it
Mark Borgerson


Re: arm7 atmel vs others
Quoted text here. Click to load it

Yep.. we just ran out of pins, although this was a small and simple device.
I guess I'm too used to MMC2114 and all its I/O pins.. :-I

  -jm

Re: arm7 atmel vs others
snipped-for-privacy@pyy.embedtronics.fi says...
Quoted text here. Click to load it

Been there,  done that.  Had to add a latch and address decoder to the
last project because I ran out of output pins.   Luckily,  I had a chip
select and  a lot of spare address space, so it only took a 74LCX32 and
a 74LCx574.

I think there's a rule that I/O requirements always equal pins available
plus 1.  If you add more pins,  the customer feels cheated if they
don't get used!


Mark Borgerson


Re: arm7 atmel vs others
<snip>
Quoted text here. Click to load it

  Sounds like an oops, but could be to protect you from yourself, as the
'INT then Check' is not guaranteed to give the correct answer.
  As chips get larger, they loose the time-determinism of smaller uC, so
this design need method needs some modify.

Quoted text here. Click to load it

  Zilog have that (not quite64KB), in the eZ80, and there are 80C51's
with Ethernet on-chip, so I'm sure ARM variants will be 'in the works'.

-jg


Re: arm7 atmel vs others

<snip>
Quoted text here. Click to load it

This new Infineon TC1130 device looks 'packed'
One of the few I've seen with all 3 : Ethernet/CAN/USB

- 10/100 Ethernet
- USB
- 4 x CAN
- many Serial ports
- MMU and FPU
- Runs Linux
- 144K RAM
- 200 MIPS
- 64 bit local bus
- price e12.05/10K

http://www.infineon.com/cgi/ecrm.dll/ecrm/scripts/prod_ov.jsp?oid50%588&cat_oid=-8138

[No flash]
-jg




Re: arm7 atmel vs others

"Rick" wrote...
Quoted text here. Click to load it
bus.
device
instead.


For external bus versions also look at (sampling stage):

http://my.semiconductors.philips.com/pip/LPC2194JBD64.html
http://my.semiconductors.philips.com/pip/LPC2210FBD144.html
http://my.semiconductors.philips.com/pip/LPC2214FBD144.html
http://my.semiconductors.philips.com/pip/LPC2290FBD144.html
http://my.semiconductors.philips.com/pip/LPC2292FBD144.html

From a Robert Buadu post in the LPC21xx forum:

http://groups.yahoo.com/group/lpc2100 /


Regards,
Arie de Muynck



Re: arm7 atmel vs others
Quoted text here. Click to load it
as
Quoted text here. Click to load it
slow!
Quoted text here. Click to load it

All flash is pretty slow.  I'm not sure why this is, but I know even
with the onboard flash it is slow.

Quoted text here. Click to load it

The Philips LPC2xxx chips have "0 wait state" flash, but don't belive
that it is truely 0 wait state.  They fetch 128 or 256 (I don't remember
which) bits from Flash at one time.  But in essence, this works like a
multiple level pipeline, you have to ask for the fetch multiple clock
cycles in advance of needing it.  On instruction fetches this is fine
until you have a branch, then the current 256 bit word and the one being
fetched have to be thrown away and a new fetch started.  If it is a data
access, it won't begin until; 1) it is requested and 2) the current
fetch completes (I assume).  So the wide word technique helps, but don't
count your clock cycles until they are measured.  :)  

A cache will likely do as much good and works for all memory, not just
the Flash.  


Quoted text here. Click to load it
an
Quoted text here. Click to load it

I thought you needed 8 channels of ADC?  Doesn't the LPC2214 only have
4?  Don't assume that these ADC will give you the full range of the bits
counted.  Many ADC claim a given number of bits for resolution, but the
AC characteristics leave a lot to be desired.  I suggest that you use
both external ADC and DACs and keep them well separated from the digital
portions of your design, unless you really don't need much accuracy and
the noise is not an issue.  


Quoted text here. Click to load it

I have been told late this year.  They have the 2114 and 2124 out now.
But they were supposed to have these parts in the very small HN64
packages, but that has been delayed without explanation.  

Take another look at the OKI ML67Qxxxx parts.  The 4000 series runs at
33 MHz and the 5000 series runs at 60 MHz and has on chip cache.  The
URL is http://www2.okisemi.com/us/docs/MCUTables-9.html .  Avoid the main
site and stick with the US site.  OKI can have some pretty messed up web
stuff.  


--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others

Quoted text here. Click to load it
like
such as
One
slow!
Quoted text here. Click to load it
flash
from
comparing
come
timers,
my
me an
it
bus.
device
instead.

Hi again Rick,

I did as you suggested and took another look at the OKI part.  That is a very
nice chip...it has about everything I need, is in stock at the distributor (that
is a nice feature!) and is in the same price range as the other parts (about $14
for a ML67Q5003).  I should have listened to you earlier.  :-)

So, how well does the SDRAM interface work?  It states the device supports a
glueless connection to up to 64MB of SDRAM via its memory controller.  That
sounds like a cheap way to get a boatload of highspeed memory...

I will dig into the data sheet and any app notes some more.  Thanks for all your
help!

Rick



Re: arm7 atmel vs others
Quoted text here. Click to load it
(that
Quoted text here. Click to load it
$14
Quoted text here. Click to load it

I don't know what your volumes are, but I have seen prices of under $10
on this part.  Check with your distributors.  Often they give you up to
20% off just by asking.  I find that waiting a few weeks and asking
again can get you another 10% off if you say you are making a final
decision.


Quoted text here. Click to load it
your
Quoted text here. Click to load it

I have an eval board from OKI, but I have done nothing with it since it
pretty much requires a full development system to make it do anything.
I have a board on order from Cogent, but I am getting tired of waiting
on them too.  I'm not sure what their story is.  I need to call them
this week.  

There is an English company making a new dev board, but it is not ready
yet.  I plan to do our software in Forth which is not commonly
supported.  I found New Micros (NMI) who sells several (or many even)
boards hosting Forth.  They are working on an ARM board with Forth using
the Philips chip.  I am trying to talk them into using the OKI chip.
You might want to send them an email asking about an OKI ARM board.  The
more people ask, the more likely they are to make something.  

Right now most of the small boards will use the Philips chip because it
is so small.  But it is too small for a lot of stuff.  It really is much
more like one of the 8 bit MCUs.  

--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.
Re: arm7 atmel vs others

Quoted text here. Click to load it
<snip>
Quoted text here. Click to load it

  Not quite. Fundamental memory bandwidth matters, so while you are
right that a branch will be the slowest, the CPU MIPS across blocks is
determined by nett memory bandwith.
  Thus the wider, on chip FLASH will give much higher performance than
a narrower, off chip solution.

  It does mean that cycle-determentistic operation is unlikely, so users
comming from smaller uC should be aware of that.

-jg


Re: arm7 atmel vs others
Quoted text here. Click to load it
come
Quoted text here. Click to load it

I think there are too many other variables for you to make that claim
with a certainty.  As I pointed out, the memory bandwidth has a high
waste factor when branching occurs *OR* the processor needs data from
the flash.  You can't say this will be faster than a cached Flash unless
you run a specific benchmark.  A lot of funny things happen when you
actually run code.  

BTW, no one was comparing off chip Flash.  The comparison is on chip,
wide Flash vs. on chip, narrow Flash with cache.  


Quoted text here. Click to load it


--

Rick "rickman" Collins

snipped-for-privacy@XYarius.com
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline