Advice neede: Atmel or Philips ARM

Noone <noone@wrenchman.com> writes:

> 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?

"Fully Static Operation: Up to 55 MHz at 1.65V and 85&#4294967295;C Worst Case
Conditions"

Bottom of page 2.

-- Jim

"Noone" <noone@wrenchman.com> skrev i meddelandet 
news:442348D2.470745D7@wrenchman.com...
>
>
> 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
>

The SPI, USART can run at clock speed, I.E: up to 55 MHz.
The SSC can run at clock speed/4

There is however an additional limitation, because the I/O buffers are 
limited to about 30 MHz,
so you would get a 27,5MHz SPI, UART, and 13,75 MHz SSC.

I hear new I/O buffers will remove this limitation (in future chips)



-- 
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 

> 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!!

Or copy the "small" interrupt routines to SRAM...

>
>> 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.
> 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.
>

I believe the 0,9/0,79 MIPS comes from ARM themselves, but they
might of course have overstated the Tumb Performance.

>> > 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.

And there are signals which are not part of the I/O and still are useful
4 ADC channels
2 USB Device signals
So you could consider it to be 38 I/O if you wanted to.

> 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.

And if you need to run high speed communication, i.e. to a Bluetooth 2.0 EDR
at a couple of Mbps, then you need fast interrupts due to lack of DMA.

And again, if you really need speed, AT91SAM9261 will be 3 x faster than the 
LPC2xxx
without an expensive external memory system. (A 1 Mb dataflash is 
inexpensive...)


> An Schwob.
>
> btw. I do like the ARM9 device you mentioned ;-)
> 

> 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.
>


Yes, this is unfortunate, but is not present in the larger devices 
(S128/256).
I guess this will be fixed in later revisions.

-- 
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 

Some of your statements are actually mis-statements, but nothing major.


If you want a chart to help compare most of the major ARM MCU makers
(chips with both ram and flash) go to http://www.gnuarm.com.  Go to the
Resources page and scroll down to the ARM Chips section.  There are
three links for info including two PDF files.  There are a couple of
known errata which have not been fixed yet.  The Philips LPC2194 is the
one I can think of off the top of my head.  This is shown as
"Discontinued" and that is not correct.  Please let me know if there
are more.


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.

If anyone wants to do some benchmarking to determine relative speeds of
various parts under different conditions, I would be happy to post that
on the web site.

> 2. Offers more I/O pins in the same 64-pin package

I know the ADUC70xx parts don't multiplex ADC inputs with digital.  Are
the SAM7 parts the same way?  That would mean you have more than the
stated number of I/O if you are using the ADC inputs.

> 3. There are more ready to go boards available e.g. from Keil, Olimex,
> IAR, embeddedartitst.com and so on.

I think this is in the noise unless you are not building a board.  Then
the selection is not about the chip, it is about the board.

> 4. Huge user community support in Yahoo group
> http://groups.yahoo.com/group/lpc2000/

What about http://groups.yahoo.com/group/AT91SAM ???  What are we,
chopped liver?


> 5. Philips focus on ARM, there seem not to be the internal wars like
> AVR32 versus ARM?

Wars...  what drama have you seen?  I have Atmel people in our office
every couple of weeks and I have not once had them pit one part against
the other.  In fact, they barely mentioned the AVR32.

> 6. Erratas get actually published!  And the LPC214x Errata Sheet is
> very slim.

The SAM7 errata is in the back of the data sheet!  Talk about "slim",
it doesn't even require its own document.

> 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

Is there something lacking in the SAM7 family?  I don't think it is
about how many part numbers a vendor has, it is about what the parts
can do.

> 11. Two 10-bit ADCs, one 10-bit DAC

Which part has the DAC?  I don't have that in my chart.  I guess I have
another errata to fix.


> What are reasones to go with Atmel?
> 1. Your connections to Atmel if you have personal ones. This can be a
> big one!

I can tell you that I get a lot of support from the distis on the Atmel
parts.  I don't seem to get the same level of exuberance from the FAEs.
 I get the feeling that they aren't as up to speed on the Philips
parts.  I know that a couple of years ago they switched from sales reps
to disti FAEs and they may still be ramping up the learning curve.

> 2. Integrated DMA if you can use it the way it is implemented, the
> Philips DMA only supports the USB

I have not done any tests myself, but I have seen data from Atmel
showing that at higher data rates the ARM CPU is running out of MIPs
without the DMA.  It would be nice to have benchmark data that we can
verify.


> 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.

We are comparing porting an existing design based on the ATmega128 vs
using an ARM MCU for a new project.  So far we have not found a reason
to stay with the ATmega128, including power and cost!  We have some
concerns with not having an EEPROM, but no real requirements to have
it.

On Thu, 23 Mar 2006 12:30:35 +1000, Peter Jakacki <peterjak@tpg.com.au> 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*
>

Perhaps ask these people when their bga board will be ready.

http://www.schmartboard.com/index.asp?page=products_bga

"Eric" <englere.geo@yahoo.com> writes:
> 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.

Amen, brother!

One wonders what the instruction set designers were
smoking when they devised the basic scheme.  Using
four bits for conditional execution which is rarely
anything but "always", using another three bits for
a third operand which isn't often used, rotating
immediate operands right instead of left shifting,
...  It's easy to see how to pare the 32-bit
instructions to 16 bits.

There are some clever things that can be done with
the instructions as designed, but it must drive
people trying to develop compiler code generators
to drink trying to get the use correct in other
than a rudimentary form.

>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.

The edge connector is for the BDM pins.
However we have a fulluy usable toolset using only the serial port,
the BDM can be used, but it is not required.



>
>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

Our compiler if GCC based.
We aslo include RTOS and a bunch of support libraries and code.


>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.

I love the Coldfire.
The assembly makes sense!
(I also like the AVR, I dislike, arm, pic and PPC assembly ugh!)

Paul

pbreed@netburner.com wrote:
>> 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.
> 
> The edge connector is for the BDM pins.
> However we have a fulluy usable toolset using only the serial port,
> the BDM can be used, but it is not required.
> 
> 
> 
>> 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
> 
> Our compiler if GCC based.
> We aslo include RTOS and a bunch of support libraries and code.
> 
> 
>> 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.
> 
> I love the Coldfire.
> The assembly makes sense!
> (I also like the AVR, I dislike, arm, pic and PPC assembly ugh!)
> 
> Paul
> 

Add msp430 to the list of sensible assembly.

PIC assembly has some of the least pronounceable and least obvious 
mnemonics I've ever seen - can you tell at a glance what "btfsc" (or is 
it "btscf"?) should do?

However, nothing can beat the PPC "Enforce Inorder Execution of Input 
Output" for its sound - I suspect the mnemonic, and then figured out 
what it could stand for.

> PIC assembly has some of the least pronounceable and least obvious
> mnemonics I've ever seen - can you tell at a glance what "btfsc" (or is it 
> "btscf"?) should do?
>

    Thats easy

    btfsc    ; BiTFuSCate Accumulator
                ; Webster: Fuscation, n. a. darkening; obscurity. [Obs]

    I.E: some kind of unpredictable operation of which the least said is 
better ;-)

    btscf    ; BitfuSCate rotating Flags
                ; Will randomize Accukumulator similar to operation above 
AND make
                ; the status flag register flicker in a random sequence

-- 
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