arm7 atmel vs others

In my new arm7 design I was biased toward the atmel AT91 seriesbecause I like the AVR chips so much, but after some research and pointers by nice foks such as rickman and Leon, I decided to look toward other manufacturer's offerings. One thing I discovered is that the flash in the atmel chips (which have it) is slow! Thus using a ball grid type package such as the AT91FR40162 with 2Meg of flash does not give you high program execution speed. I guess you can just run from the 256k of on chip sram, but that should be taken into account when comparing this chip to others.

The Phillips LPC2214 has 16k of sram and 256k of flash, but that flash is fast...0 wait state. The bonus features you get on this chip that do not come on the 40008 or 40162 are dual SPI, I2C, 8 channel 10 bit ADC, 32 bit timers, dedicated PWM, and on chip crystal oscillator with PLL.

The LPC2214 seems like a better match for my application since it eliminates my need for an external ADC, external boot flash, external crystal, and gives me an SPI interface to my DAC. If the prices of the LPC21xx are any indication, it will also cost quite a bit less than the AT91.

I could actually use a LPC210x except for the lack of an external memory bus. If I took a simplistic but slow method of interfacing to a compact flash device (8 bit memory mode) using general IO, I guess I could use one of these instead. They are dirt cheap at around $5 from avnet (in stock).

Any idea of when the LPC2214 will come to full production?

Rick

Reply to
Rick
Loading thread data ...

"Rick" skrev i meddelandet news:r3uXb.21596$ snipped-for-privacy@nwrddc01.gnilink.net...

like

such as

One

slow!

flash

from

comparing

The big benefits are

  • small size (if you want 2 MB)
  • somewhat higher speed.when executing from SRAM (Philips is not zero waitstate unless you are in sequential access) If you make dataaccesses to Flash, then this could trash the flash access as well.
  • It is much nicer to develop using SRAM than using Flash. It is a little bit short on peripherals though compared to the rest of the AT91.
--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

bus.

device

instead.

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

formatting link
formatting link
formatting link
formatting link
formatting link

From a Robert Buadu post in the LPC21xx forum:

formatting link

Regards, Arie de Muynck

Reply to
Arie de Muynck

as

slow!

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

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.

an

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.

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
formatting link
Avoid the main site and stick with the US site. OKI can have some pretty messed up web stuff.
--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

The AT91 has its advantages and disadvantages like all the other chips. I am beginning to understand that. The 40008 is certainly the only arm7 I have found with such large sram.

Thanks,

Rick

Reply to
Rick

like

such as

One

slow!

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

Reply to
Rick

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

Reply to
Jim Granville

(that

$14

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.

your

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

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

come

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.

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

The main problems with these chips (IMO) are:

  • slow and narrow FLASH (which still uses "lots" of power)
  • no caches for compensating the slow FLASH
  • no MMU to protect executable code in SRAM
  • the internal FLASH requires the external address/data bus, which greatly reduces the number of I/O pins available, even in single-chip applications

Philips seems to run pretty fast, thanks to the wide FLASH and the MAM unit which acts like a small cache. (But yes, the FLASH is smaller..)

It seems the more I learn about Atmel, Philips etc., the more I like Motorola.. We've had a few surprises with Atmel and Philips ARM MCU's so far (it was a mistake to expect the same level of intelligence that has been present on Motorola chips since the Big Bang).

-jm

Reply to
Jukka Marin

If you want cache, check out the OKI ML67Q500x series. They come with

32 kB of SRAM, up to 512 kB of Flash and tons of peripherals as well as an external bus. Oh yes, and an 8 kB cache. :)

What do you mean about "intelligence"? Are you talking about the features on the chip or the support from the vendor?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

I kinda like the physical size of the LPC210x. :-) But no, it doesn't fit larger designs. I'll check out that OKI (although I'm working on a AT91RM9200 design right now - are there good appnotes / schematics out there for comparison and checking our own?)

I was talking about the peripheral features. For example, if you put a pin on the LPC210x in CAPture mode, it seems you can't read the pin state any longer. We have been using input capture on both edges and when an edge arrives, checked the pin state - this works on Motorola chips (HC11, HC12, MCore etc.) but not on the Philips chips. Now that you know it, it kinda makes sense - if a pin is connected to the CAPture logic, it is disconnected from GPIO - but I still think it's pretty dumb.

Also, the I²C pins of LPC210x seem to be in open drain mode even when configured as MAT/CAP pins - despite of the fact that the data sheet only mentions "open drain" for I²C mode. Of course, we didn't expect this, so our design has no pullup on the MAT output.. nothing like this has ever hit us with Motorola parts.

We are seeing some problems with the SPI, as well - but we don't know what's going on for sure. It just seems that SPI doesn't want to start up in master mode if we want to use the SS pin as GPIO (we ran out of pins, see ;-)

Umm.. "support from the vendor".. Is there such a thing for the Philips chips? :-)

Anyway, I think the ARM based chips are pretty interesting in general and as the prices drop, we can afford "real MCU's" in more and more applications (instead of kludgy things like PICs we have been using for a decade).

Somebody make a small chip with 256 kB or more FLASH, 64 kB SRAM,

10/100 Mbps Ethernet and some UARTs, timers etc.. :-)

-jm

Reply to
Jukka Marin

Yes, the Philips LPC210x parts are very small. But I am not sure why you need a 32 bit processor if you only need to control some GPIO or SIO ports. Of course you could say, why not? with the incredibly small price difference to an 8 bit processor. But the Philips parts are currently just too limited for my designs.

Unless you know the input does not change very fast, this could produce errors. But yes, I agree that it seems odd that you can't read the pin. I'm not sure how the OKI parts work in this case.

I'm not familiar with MAT/CAP. How about when it is a GPIO, is it only open drain?

I am always very leery of using every last pins or sharing pins between functions. I want to take a pin from the handshakes for the UART on the OKI part since I don't have a receiver for that one. I want an output to a driver instead. But I have been told it is a group and can't be split. I'll verify this at some point.

I belive there is both support from the vendor and there seems to be a large and growing grassroots user base. I would like to see some of this for the OKI chips.

Heck, the Philips and OKI parts are already as cheap if not cheaper than a lot of the PICs that have much less capabilities.

Check with OKI in a few more months. I have been told Ethernet is the next one out of the shoot!

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

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.

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

Reply to
Jim Granville

They seem to be a nice fit for some ideas I have for sensors with reasonably complex data processing. My last ARM project collected a lot of data from various sensors, and did a bunch of statistics, (medians, percentiles, std. deviations, even some FFT-related calculations) before storing the data in serial flash memory. I need FP calculation speed and RAM size that I couldn't find in an MSP430 or most 8-bit processors. The hardware-assisted serial ports on the AT91R40807 were also quite handy, but I could probably do without them if I switched to one of the LPC210X chips.

Mark Borgerson

Reply to
Mark Borgerson

Are you saying that the ARM7 chips have floating point? I was not aware of that. Or are you saying that they will emulate floating point much better than the 8 bitters? I believe some of the 8 bit chips have hardware multiply, 8x8 in the MSP430, IIRC.

I am not saying there are NO applications that would benifit from the LPC20xx chips. But it just seems like everyone is facinated with them when they only fit a niche really. Are these 32 pin MCUs really that much more versitile than any other device?

--
Rick "rickman" Collins

rick.collins@XYarius.com
 Click to see the full signature
Reply to
rickman

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

formatting link

[No flash]

-jg

Reply to
Jim Granville

In ARM7TDMI the "M" stands for multiply. It is a 32x32->64 multiplication, takes only a few machine cycles. Making such a beast with a 8x8->16 multiplication (as in MSP430/AVR/PIC) would take

16 multiplications and a big bunch of 8-bit additions. Slooooooow.

I am not aware of any ARM7 -processors with fp, but there is something like VFP10 coprocessor for ARM10 (Vector Floating Point, IIRC), which may then be on the same silicon.

We try to make everything with fixed-point arithmetics. The

32-bit resolution it is usually more than enough with real-world data. Especially the 32-bit MAC operation makes some things rather enjoyable. For example, a 32-bit fixed-point FFT is not that slow.
--
> I am not saying there are NO applications that would benifit from the
> LPC20xx chips.  But it just seems like everyone is facinated with them
 Click to see the full signature
Reply to
Ville Voipio

Heck, the Philips and OKI parts are already as cheap if not cheaper than a lot of the PICs that have much less capabilities.

//-------------------

As someone who uses PIC/AVR/8051 on a regular basis, the Philips and OKI parts are really attractive, however getting hold of them easily is a real issue at present. Most of the projects I work on involve small quantities (ie. a couple hundred), and as a result, I tend to be pretty low priority to the distribution companies. Component availability is therefore a prime consideration when choosing parts.

I can buy PICs or 8051 from a large number of sources in the UK in any quantity, without any hassle. If I can't buy the exact part, chances are a similar version is available which is pin and code compatible. AVR is a little more difficult, especially if you want access to the full range, but if I can't get them locally, then Digikey give me excellent service.

We have looked at the Philips range and have a dev board which we have been using to evaluate various tool chains, and from a technical standpoint, I'm really like it (apart from the lack of code protection).

I think Philips need to get this range into the catalogue suppliers like Farnell and Digikey, at which point it should really take off.

Martin

Reply to
Martin Walton

Hmm, I thought it was an 16 x 16 => 32...

--
Best Regards,
Ulf Samuelsson   ulf@a-t-m-e-l.com
 Click to see the full signature
Reply to
Ulf Samuelsson

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.