Forums

Advice neede: Atmel or Philips ARM

Started by Meindert Sprang March 22, 2006
Meindert,

first advice, do not compare the LPC2104/5/6 to the SAM7S but the
LPC214x because that is the equivalent device.

Doing this, it is more difficult to find reasons to go with the Atmel
device.

1. Philips LPC214x is faster, in particular executing from Flash, 60
MHz close to 0WS in the faster ARM mode.
2. Offers more I/O pins in the same 64-pin package
3. There are more ready to go boards available e.g. from Keil, Olimex,
IAR, embeddedartitst.com and so on.
4. Huge user community support in Yahoo group
http://groups.yahoo.com/group/lpc2000/
5. Philips focus on ARM, there seem not to be the internal wars like
AVR32 versus ARM?
6. Erratas get actually published!  And the LPC214x Errata Sheet is
very slim.
7. If for what ever reasons you want to have trace debug that is a
Philips only feature.
8. Larger Flash device available. 512k Flash / 40k SRAM
9. Faster I/O up to 15 MHz with the fast I/O feature
10. More code compatible brothers and sisters in the Philips LPC2000
family
11. Two 10-bit ADCs, one 10-bit DAC

What are reasones to go with Atmel?
1. Your connections to Atmel if you have personal ones. This can be a
big one!
2. Integrated DMA if you can use it the way it is implemented, the
Philips DMA only supports the USB
3. More SRAM available.  256k Flash / 64k SRAM

Reasons for both:
1. ARM7 devices offer the best price / performance ratio
2. Competing vendors like Atmel and Philips will help to get new
features for the same money or even less.

May be this helps, an Schwob

Meindert Sprang wrote:
> Hi Gurus, > > I am switching from AVR to ARM. Currently, I use an ATmega162 which is > running out of code space (16kB) and performance. But I find it difficult to > choose between Atmel's ARM (looking at the SAM7S series) and thePhilips > LPC2104/5/6 series. I don't need many peripherals (yet). My current design > uses an FTDI chip for USB, I could save that by using Atmel (Philips has no > USB), but on the other hand, that makes me responsible for all the PC/Mac > drivers as well. Ethernet might be interesting later (currently using > XPort). > Thinking about each option pops up 10 new questions. Like for ethernet: I'd > like to send serial data to multiple hosts. UDP broadcasts or multiple > TCP/IP connections. In the latter case: how much resources will that cost? > > Questions, questions, questions...... > > Any answers/tips/hints anyone? > > Meindert
Well said An! I do favor the LPC2148 but I like to see apples compared 
with apples. You've kept your analysis objective enough to prove 
beneficial, not just a one way look of comparing one's strengths with 
another's weakness. Maybe somebody from the Atmel camp can add to the 
list in a similar objective manner.

The SAM7s look interesting but I haven't been swayed enough to use them 
yet. Also, BGAs turn me off whereas fine pitch smd has never ever been a 
problem. Some of the nicer devices all-round are only available in BGA 
though which means we engineers will have to come up with a viable BGA 
prototyping solution to take advantage of the goodies.

*Peter*
http://www.pbjtech.com/

An Schwob in the USA wrote:
> Meindert, > > first advice, do not compare the LPC2104/5/6 to the SAM7S but the > LPC214x because that is the equivalent device. > > Doing this, it is more difficult to find reasons to go with the Atmel > device. > > 1. Philips LPC214x is faster, in particular executing from Flash, 60 > MHz close to 0WS in the faster ARM mode. > 2. Offers more I/O pins in the same 64-pin package > 3. There are more ready to go boards available e.g. from Keil, Olimex, > IAR, embeddedartitst.com and so on. > 4. Huge user community support in Yahoo group > http://groups.yahoo.com/group/lpc2000/ > 5. Philips focus on ARM, there seem not to be the internal wars like > AVR32 versus ARM? > 6. Erratas get actually published! And the LPC214x Errata Sheet is > very slim. > 7. If for what ever reasons you want to have trace debug that is a > Philips only feature. > 8. Larger Flash device available. 512k Flash / 40k SRAM > 9. Faster I/O up to 15 MHz with the fast I/O feature > 10. More code compatible brothers and sisters in the Philips LPC2000 > family > 11. Two 10-bit ADCs, one 10-bit DAC > > What are reasones to go with Atmel? > 1. Your connections to Atmel if you have personal ones. This can be a > big one! > 2. Integrated DMA if you can use it the way it is implemented, the > Philips DMA only supports the USB > 3. More SRAM available. 256k Flash / 64k SRAM > > Reasons for both: > 1. ARM7 devices offer the best price / performance ratio > 2. Competing vendors like Atmel and Philips will help to get new > features for the same money or even less. > > May be this helps, an Schwob
>The SAM7s look interesting but I haven't been swayed enough to use them >yet. Also, BGAs turn me off whereas fine pitch smd has never ever been a >problem. Some of the nicer devices all-round are only available in BGA >though which means we engineers will have to come up with a viable BGA >prototyping solution to take advantage of the goodies. >
We have been doing Coldfire BGA's for about 5 years now. I will never go back to fine pitch. The ball to Ball spacing is much wider than the lead to lead spacing in tqfp etc... We have far fewer production problems with BGA. Our rewok guy can do BGA's just as fast as fine pitch.( With the proper tools) The BIG downside to BGA is that if you make a schematic or PCB design error they are almost impossible to rework. On prototypes we biring anything that is at all doubful out to a zero ohm jumper resistor. We offer a 32 bit coldfire in a 40 pin DIP package for development. See http://www.netburner.com/products/core_modules/mod5213.html shameless plug ;-) We could not possibly offer this product if the MC5213 was in a QFP package, it would be too big. Paul I work for Netburner.
All of my prototypes are simple double-sided PCBs which are are both 
cheap and fast to produce. I fear that BGA will force me to go to 6 or 8 
layer thereby increasing the cost and turnaround time for protos. Plus 
if I stuff the mounting of the chip, unless it is done precisely, I can 
add the cost of rework and new chips or new pcb onto that as well.

I've seen complicated prototyping solutions abound but do you have any 
sure-fire tips for a wannabe BGA prototyper?

*Peter*

pbreed@netburner.com wrote:
> We have been doing Coldfire BGA's for about 5 years now. > > I will never go back to fine pitch. > > The ball to Ball spacing is much wider than the lead to lead spacing in tqfp etc... > > We have far fewer production problems with BGA. > > Our rewok guy can do BGA's just as fast as fine pitch.( With the proper tools) > > > The BIG downside to BGA is that if you make a schematic or PCB design error > they are almost impossible to rework. > > On prototypes we biring anything that is at all doubful out to a zero ohm jumper resistor.
Peter,

> I've seen complicated prototyping solutions abound but do you have any > sure-fire tips for a wannabe BGA prototyper?
my first BGA board 5 years ago had 6 layers, all BGAs were 1.27 pitched. Two signal layers - and slightly split power and ground planes - is all it took, the board was as dense as they get, 3 BGA chips, SDRAM on both sides etc., 3 signal traces between the pads. I did reflow this boad innumerable times (I'd say 20 to 40 times..), eventually I got it to work, and it failed after 3-4 months (lost connections, the layers had begun to detach from one another etc, quite a nightmare). After that, the second board took just a single reflow and worked. All equipment it takes for prototyping is a kitchen oven and an infrared thermometer to control the temperature. Contrary on what is widespread and practiced, it is quite allright to have a via in the middle of every BGA pad (talking 1.27 pitch BGA), 0.3 or 0.2 mm drilled. This gives you access to all signals while testing, although it costs an extra operation - you _must_ reflow the BGA chips once belly (balls) up with some flux so there are no "cold" balls, otherwise they (the cold balls) get detached during reflow and flow down the via ... I have had this at the beginning, 2-3 balls per BGA seems to be the case (I guess this has been responsible for 1 or two of the many initial reflows I did until I figured out the medicine). Once you reflow the BGA with a decent amount of flux, things get quite stable. Under the score, be prepared for a reasonably tough fight until you get everything fine, but as long as the BGAs are 1.27 (I'd speculate 1mm as well), it is doable, nothing which should stop you. Ah yes, beware too much flux under the BGA - it can float away and get soldered with an "offset"... I have had this as well. Placing the BGA is difficult and you will have to spend all the time it takes to make sure it is properly positioned, I use the flux to have the BGAs lightly stuck to their positions. Hope this helps somewhat... Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Peter Jakacki wrote:
> All of my prototypes are simple double-sided PCBs which are are both > cheap and fast to produce. I fear that BGA will force me to go to 6 or 8 > layer thereby increasing the cost and turnaround time for protos. Plus > if I stuff the mounting of the chip, unless it is done precisely, I can > add the cost of rework and new chips or new pcb onto that as well. > > I've seen complicated prototyping solutions abound but do you have any > sure-fire tips for a wannabe BGA prototyper? > > *Peter* > > pbreed@netburner.com wrote: > > We have been doing Coldfire BGA's for about 5 years now. > > > > I will never go back to fine pitch. > > > > The ball to Ball spacing is much wider than the lead to lead spacing in tqfp etc... > > > > We have far fewer production problems with BGA. > > > > Our rewok guy can do BGA's just as fast as fine pitch.( With the proper tools) > > > > > > The BIG downside to BGA is that if you make a schematic or PCB design error > > they are almost impossible to rework. > > > > On prototypes we biring anything that is at all doubful out to a zero ohm jumper resistor.
> 1. Philips LPC214x is faster, in particular executing from Flash, 60 MHz > close to 0WS in the faster ARM mode.
And the AT91SAM7 is faster in Thumb Mode at the same frequency due to faster flash. The AT91SAM7 flash runs at 30 Mhz over the full temp range. Rons at 48 Mhz zero waitstates up to a certain temperature. The Philips flash is slow - 20 Mhz, so when you do not see a sequential fetch, you lose out. This results in: SAM7: Zero waitstate in burst and one waitstate in non-burst. LPC: Zero waitstate in burst and two waitstates in non burst. This might be offset by the 5 Mhz higher clock frequency. Running in ARM mode makes the time when you have to switch to a larger part shorter. ARM mode could add 30% more code. ARM also uses more code in many benchmarks compared to the AVR. If we assume 10% more code for the ARM Thumb and add 30% for ARM mode you get: 16kB * 1,1 * 1,3 = 23 kB equivalent. A 32 kB device would allow growing 32/23 = 40 % if yo run in ARM mode It would allow to grow with 82 % if you run in Thumb mode. You lose about 12% of the performance in Thumb mode. If you need more, then you have the code compatible AT91SAM9261 part running at 200 MIPS from zero waitstate internal 160 KB SRAM. I guess the choice of the mega162 over the Mega16 either means that you need an external bus or the dual UART. Most people use it because of the dual UART. The DMA will reduce the performance requirement for any communcations application significantly, and makes it easier to run at low power. It is a much better solution than the FIFO used by the LPC. If you happen to run RS-485, then you leave the LPC in the dust....
> 2. Offers more I/O pins in the same 64-pin package
If you start with the 44 pin ATmega162 device, then this is likely not an issue. You rather have the 48 pin SAM7S32... If you want to use the JTAG, you start to lose the I/Os.
> 3. There are more ready to go boards available e.g. from Keil, Olimex, > IAR, embeddedartitst.com and so on. > 4. Huge user community support in Yahoo group > http://groups.yahoo.com/group/lpc2000/
www.at91.com should be a nice alternative
> 5. Philips focus on ARM, there seem not to be the internal wars like AVR32 > versus ARM?
The AT91 and AVR32 are in different divisions with their own profit and loss. There is no overlap between the AVR32 and the SAM7 parts. - At least not at this time.
> 6. Erratas get actually published! And the LPC214x Errata Sheet is very > slim.
The Erratas do get published, since they are in the datasheet.
> 7. If for what ever reasons you want to have trace debug that is a Philips > only feature. > 8. Larger Flash device available. 512k Flash / 40k SRAM
Yes the step from 16 kB to 512 kB is obvious.
> 9. Faster I/O up to 15 MHz with the fast I/O feature > 10. More code compatible brothers and sisters in the Philips LPC2000 > family
They need to redesign parts to fix
> 11. Two 10-bit ADCs, one 10-bit DAC
Not likely to be needed if you start w the mega162.
> What are reasones to go with Atmel? > 1. Your connections to Atmel if you have personal ones. This can be a big > one! > 2. Integrated DMA if you can use it the way it is implemented, the Philips > DMA only supports the USB > 3. More SRAM available. 256k Flash / 64k SRAM
More likely the next step would be 32 kB Flash and 8 kB SRAM.
>
-- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may bot be shared by my employer Atmel Nordic AB
Paul,

That's a cool 40 pin product!

Does it have BDM pins? I'm used to BDM on the hc12 devices and it would
be hard to give it up. I'd also need a low cost BDM adapter, perhaps
for serial or parallel port on a PC.

I'm assuming you disribute the gcc compiler (I saw that you use
DEV-CPP, but the compiler wasn't clear)?

This dev kit looks like a good starter package:
http://www.netburner.com/products/development_kits/embedded_development.html

I'm starting to look at Coldfire since I recently tried writing an
assembler routine for an ARM chip and I almost went mad! ARMs are
cheap, but there're very hard to code in assembly language.

Eric

Ulf,

thank you for not disappointing me, I counted on your response :-)

Ulf Samuelsson wrote:
> > 1. Philips LPC214x is faster, in particular executing from Flash, 60 MHz > > close to 0WS in the faster ARM mode. > > And the AT91SAM7 is faster in Thumb Mode at the same frequency due to faster > flash. > The AT91SAM7 flash runs at 30 Mhz over the full temp range. > Rons at 48 Mhz zero waitstates up to a certain temperature.
We tested the Philips Flash to higher than 40 MHz without waitstates, you did it with the SAM7 to 48 MHs, it is just not specified, so let's compare the specified values, Atmel 30 MHz without a hickup Philips 20 MHz without any brakes, one point for Atmel if your target frequency is higher than 20 and less / equal 30 MHz
> The Philips flash is slow - 20 Mhz, so when you do not see a sequential > fetch, you lose out.
Running benchmarks we did see a slow down between running from SRAM at 60 MHz and running from Flash with the MAM activated and MAMTIM = 3 (that is the way to program it according to spec). The slow down was in the range of 5%, which gives us an effective frequency of 57 MHz running from Flash in ARM mode.
> > This results in: > SAM7: Zero waitstate in burst and one waitstate in non-burst. > LPC: Zero waitstate in burst and two waitstates in non burst. > This might be offset by the 5 Mhz higher clock frequency. > > Running in ARM mode makes the time when you have to switch to a larger part > shorter. > ARM mode could add 30% more code.
Absolutely correct. As you and every experienced programmer knows, there are parts of the code that need performance and other parts that need to be executed without real-time needs. So ARM adds 30% more code to the small program parts that need to be fast, so what. In interrupt service routines where speed is needed the most, you will enter in ARM mode no matter what. So to become faster with the SAM7 you need to switch first to the slower mode due to its bus width limitation, double brake!!
> ARM also uses more code in many benchmarks compared to the AVR. > If we assume 10% more code for the ARM Thumb and add 30% for ARM mode you > get: > > 16kB * 1,1 * 1,3 = 23 kB equivalent.
Correct but ignores the fact that most programs use a mixed mode, most of the code in Thumb mode and speed critical parts in ARM mode. So between having the whole program running in Thumb mode, resulting in your 82% and the optimized version, running 10% in ARM mode and 90% in Thumb mode the result is close to a 80% effective code area increase while adding significant performance.
> A 32 kB device would allow growing 32/23 = 40 % if yo run in ARM mode > It would allow to grow with 82 % if you run in Thumb mode. > You lose about 12% of the performance in Thumb mode.
Incorrect!! According to Steve Furber "ARM system on chip architecture" who is one of the original ARM architects, ARM code is 40% faster than Thumb code (Chapter 7.10 Thumb applications), given you do not have a bandwidth limitation like the Atmel SAM7 has with its 32-bit bus versus the Philips 128-bit wide bus.
> > 2. Offers more I/O pins in the same 64-pin package > > If you start with the 44 pin ATmega162 device, then this is likely not an > issue. > You rather have the 48 pin SAM7S32... > If you want to use the JTAG, you start to lose the I/Os.
Oops the 64-pin SAM 7 offer 32-pin I/O according to the DS, so starting with a 44-pin mega162 might give you more I/O than the SAM7 but less than the LPC2000. May be as a summary from my end. If you need the speed running from Flash, you only get it in ARM mode and there the LPC2000 is definitely a lot faster than the SAM7. In fact it is slightly faster than the SAM7 running from SRAM. If you need to put as much code as possible into the memory, the SAM7 is faster running the same clock rate, the LPC2000 can run a higher clock rate and make up for the fast slow mode. An Schwob. btw. I do like the ARM9 device you mentioned ;-)
Grzegorz Mazur wrote:
> Meindert Sprang wrote: > > Hi Gurus, > > > > I am switching from AVR to ARM. Currently, I use an ATmega162 which is > > running out of code space (16kB) and performance. But I find it difficult to > > choose between Atmel's ARM (looking at the SAM7S series) and thePhilips > > LPC2104/5/6 series. I don't need many peripherals (yet). My current design > > uses an FTDI chip for USB, I could save that by using Atmel (Philips has no > > USB), but on the other hand, that makes me responsible for all the PC/Mac > > drivers as well. Ethernet might be interesting later (currently using > > XPort). > > I've chosen Atmel: > - USB (available in Philips 214x series) > - easy code download via UART or USB > - easy interfacing to 5V > - not too many known errors (Philips errata is huuuge) > - nice feature of set/reset registers in peripherals
A couple of notes on issues we have found... The AT91SAM7S32 and 7S64 both have an errata against them that makes the quiescent current jump up to about 100 uA (IIRC) if you try to use the JTAG pins. One of them has a flaw that causes a partial failure of an oxide at voltages above 2.0 volts. Once failed, it still works, but the static current jumps way up. So JTAG can't be used if you need the low static current. The SAM7 parts all include DMA for the peripherals which allows the CPU to do a lot more work if your I/O data rates are high. Depending on your mix of I/O speeds, this can make the CPU run a lot faster than the Philips parts.

An Schwob in the USA wrote:

> Ulf, > > thank you for not disappointing me, I counted on your response :-) >
I have spent the last two weeks researching ARM architectures and reading the spec sheets. Based on the peripherals structure, I like the SAM7 family. But what is really glaring in its absence is the specification of how fast they can run and in what mode. (My data sheet is 61750 dated 13 Feb 2006) Now I may have been staring too intently and missed this part. So straight up question: How fast can the SAM7S64 run in ARM and Thumb modes at a given clock speed? Blakely