Favorite Philips/NXP LPC21xx websites/forums?

On 17 Sep 2006 11:28:11 -0700, "rickman" <gnuarm@gmail.com> wrote:

>Eric wrote:
>> John wrote:
>>
>> > It seems their AT91SAM32 is the "low-end".  Fortunately with Philips in
>> > the game, the price on the AT91SAM parts has come down.  They're now
>> > $5ish in 100 pcs quantities
>>
>> Sounds good - it's worth a look. I bet they use more current than the
>> 2103, but that's not an issue if you aren't using battery power.
>
>Actually my experience is that the Atmel parts are the lowest power you
>can find.  Of course this will depend on any number of things and since
>Philips is a close second, for any given app the Philips parts may be
>lower power.  But don't assume the Atmel parts are hogs, they are not!
>
>
>They are a bit more money than the Philips parts.  I don't know exactly
>what makes them more expensive, but we buy a lot of parts and get high
>quantity pricing with a lot of competition.  Even so, the Atmel prices
>were all a bit higher than the equivalent Philips parts.  We went with
>the Atmel parts on our first few ARM designs because most of our stuff
>runs from battery and power is very important.  The Atmel parts have
>some clear advantages for low power operation.
>
>
>> > Anyway, I'd be interested to hear other minuses/pluses of the LPC parts.
>>
>> Despite my negative comments about the company, the 2103 has a lot
>> going for it. It has high speed bit toggling (I think it's 3 or 4 times
>> faster than most Arm7's), and I think all lpc2000 devices have the MAM
>> that lets them run full speed from flash. The SAM devices run about
>> half speed from flash.
>
>The bit toggling on the newer Philips parts is a lot faster than the
>older Philips parts, but the Atmel parts have always been fast.  The
>original Philips design put the GPIO interface on the slow internal
>bus.  They changed that with the last few iterations of new designs.
>
>
>> Although the lpc on-chip peripherals are simpler than those of the SAM,
>> that simplicity can be a good thing if you're in a hurry to get
>> something working.
>>
>> I haven't compared the errata sheets, but I'd expect the SAM to have
>> more items there because their chips are generally more complex. But I
>> don't mean this as a slam against Atmel because every company has these
>> kinds of issues when they pack more stuff into the chip.
>
>You really shouldn't say stuff like this unless you look at the errata
>sheets.  You can assume anything you want, but you know what happens
>then!!!
>
>

I know as a fact and first hand that Atmel does NOT put full Errata on
their AVR documents at least.  Don't know about the ARM stuff though.
In fact, try to obtain  information on Atmel quality control programs.
Then look at somebody's quality control program like Microchip.  At
least Microchip has a quality control program and decent Errata sheets
as well as Philips/NXP.


boB
K7IQ



>> If you have a need for a battery powered Arm device, the lpc2103 is
>> your best bet today. If power isn't a concern and you just need a low
>> cost device, then compare the SAM32 against the 2103 and see how the
>> specs line up.
>
>You should look harder at the Atmel parts.  Not only do they do very
>well on battery power running full out, they have a lot more potential
>for power savings by shutting down various sections of the chip and
>even running the internal Vddcore from an external 1.8 volt source
>rather than a 3.3 volt on the internal LDO.  A very small switcher can
>give you an 80% boost in battery time just from this feature.

>>
>
> I know as a fact and first hand that Atmel does NOT put full Errata on
> their AVR documents at least.  Don't know about the ARM stuff though.
> In fact, try to obtain  information on Atmel quality control programs.
> Then look at somebody's quality control program like Microchip.  At
> least Microchip has a quality control program and decent Errata sheets
> as well as Philips/NXP.
>

The ARM and AVR are in separate division within Atmel, and they make their 
own decisions.

It would be interesting to know which AVR bugs you are referring to.

I think that if a problem can be caught at test time, it is better to  fix 
the test
program, and replace the bad parts than introduce an errata.
You want of course to inform people of a problem with a specific batch.

>
> boB
> K7IQ
>



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

On Tue, 19 Sep 2006 08:39:07 +0200, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>>>
>>
>> I know as a fact and first hand that Atmel does NOT put full Errata on
>> their AVR documents at least.  Don't know about the ARM stuff though.
>> In fact, try to obtain  information on Atmel quality control programs.
>> Then look at somebody's quality control program like Microchip.  At
>> least Microchip has a quality control program and decent Errata sheets
>> as well as Philips/NXP.
>>
>
>The ARM and AVR are in separate division within Atmel, and they make their 
>own decisions.
>
>It would be interesting to know which AVR bugs you are referring to.


This was the problem with ATmega 32s and 128s just over a year ago and
lasted about a year.  I was evidently the first in north america to
find the problem.  The Mega32 I was using was full and I was using all
of the peripherals to the max, in a power product. They referred to it
as the LPM instruction problem where, when run at close to max
frequency (16 MHz) the parts would not work correctly.  Symptoms were
numerous, but random part resetting was one common common symptom. 

Turns out the problem would get worse with increasing temperature (say
> 40 C but could also happen at 25C) and would get worse as the part
was powered up longer (say, > 1 day).  We had to power up our
processors for a day, then carefuly check the parts operation.  CRC
check worked for a short while but there appeared to be more problems
with these parts than just the LPM instructions.   Atmel did NOT send
out ANY erratas are far as I know on this problem and it was a silicon
problem not associated with any one particular batch.  Many date codes
were affected, or around the first years production.
  Yes, they supposedly fixed the problem by testing.  They must either
be throwing away a lot of parts, or selling them as the < 8MHz
version.   I slowed down the clocks on these and sometimes they would
not work at even 10 MHz.

I had to email ALL of the QA email addresses around the world on their
website until I got even a seemingly interested response.  The local
FAE was at the factory the next day.  Our company spent probably
$100,000 with this problem and not one Atmel engineer or QA person
came by.   The reports we got from Atmel on some of the parts of ours
they "tested" were basically meaningless and worthless.  They
obvioulsly kept the information to themselves. 

Atmel still denies the problem existed.  They could not show us a QA
program either.  Their QA processes were confidential.  To me that
means it is pretty nonexistent.  I was shown QA programs by other
vendors and they were proud of their QA.

Because of the way we were treated by Atmel management, I will stay
away from them in the future.  I was soured. The ARM parts may be
designed by a different group, but Atmel management is still the same
I bet.  I was not the only customer with these problems.  I emailed
with people in UK and Croatia that had very similar problems and no
support.  The guy in Croatia reported the problem before me and had I
found his posting earlier, I would have not torn out as much hair as I
did for as long as I did.

I would sum up my experience as meaning Atmel has very poor customer
support.

boB


>
>I think that if a problem can be caught at test time, it is better to  fix 
>the test
>program, and replace the bad parts than introduce an errata.
>You want of course to inform people of a problem with a specific batch.
>
>>
>> boB
>> K7IQ
>>

On Tue, 19 Sep 2006 08:39:07 +0200, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>>>
>>
>> I know as a fact and first hand that Atmel does NOT put full Errata on
>> their AVR documents at least.  Don't know about the ARM stuff though.
>> In fact, try to obtain  information on Atmel quality control programs.
>> Then look at somebody's quality control program like Microchip.  At
>> least Microchip has a quality control program and decent Errata sheets
>> as well as Philips/NXP.
>>
>
>The ARM and AVR are in separate division within Atmel, and they make their 
>own decisions.
>
>It would be interesting to know which AVR bugs you are referring to.
>
>I think that if a problem can be caught at test time, it is better to  fix 
>the test
>program, and replace the bad parts than introduce an errata.
>You want of course to inform people of a problem with a specific batch.
>
>>
>> boB
>> K7IQ
>>


Here is that very old posting from that guy in Hungary.  I thought it
was Croatia. I found this on deja-news, google groups.

Also, it looks like we have talked about this issue before, Ulf.

It also looks like Atmel has at least fixed the problem or tested out
the bad parts.  This was evidently the first year of production for
these parts.  Mega16s were fine and without problems.

 Atmel would not be my first choice for a micro though based on that
experience.

Thanks,
boB



(the old post)

From:  Deni - view profile 
Date:  Sun, Mar 16 2003 8:31 am  
Email:   "Deni" <dejan.durde...@zg.hinet.hr> 
Groups:   comp.arch.embedded 
Not yet ratedRating:    
show options  
Reply | Reply to Author | Forward | Print | Individual Message | Show
original | Report Abuse | Find messages by this author  


Did anybody had any problems using Mega32 device running at 16MHz? 
We had cca. 20% of devices that do not correctly read Flash memory as 
data constants...(using LPM instruction). Ocasionally device do not
read 
the contents of Flash correctly, usually one bit fails...If clock
frequency 
is 
reduced, it starts to behave as supposed...??? 

Dejan 

> Because of the way we were treated by Atmel management, I will stay
> away from them in the future.  I was soured. The ARM parts may be
> designed by a different group, but Atmel management is still the same I 
> bet.

How much are you prepared to bet ;-)

http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=atml&script=410&layout=-6&item_id=892818

-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

Ulf Samuelsson wrote:
> > Because of the way we were treated by Atmel management, I will stay
> > away from them in the future.  I was soured. The ARM parts may be
> > designed by a different group, but Atmel management is still the same I
> > bet.
>
> How much are you prepared to bet ;-)
>
> http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=atml&script=410&layout=-6&item_id=892818
>
> --
> Best Regards,
> Ulf Samuelsson
> This is intended to be my personal opinion which may,
> or may not be shared by my employer Atmel Nordic AB

That is one of the strangest replies to a post I have ever seen.  When
he said he thought the management was the same, he didn't mean the one
guy at the top was the same as last year.  He meant they share many
layers of management and very likely share many management products
like work processes and QA methods.

The fact that your CEO was canned is not really relevant unless he was
also the head QA manager.  Is that what you are suggesting?

>> > Because of the way we were treated by Atmel management, I will stay
>> > away from them in the future.  I was soured. The ARM parts may be
>> > designed by a different group, but Atmel management is still the same I
>> > bet.
>>
> When he said he thought the management was the same, he didn't mean the 
> one
> guy at the top was the same as last year.  He meant they share many
> layers of management and very likely share many management products
> like work processes and QA methods.

The AVR is in the microcontroller division
The AT91 is in the ASIC division
The divisions do not share managers, but both report to the CEO and COO


-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB 

On Wed, 20 Sep 2006 20:47:16 +0200, "Ulf Samuelsson"
<ulf@a-t-m-e-l.com> wrote:

>>> > Because of the way we were treated by Atmel management, I will stay
>>> > away from them in the future.  I was soured. The ARM parts may be
>>> > designed by a different group, but Atmel management is still the same I
>>> > bet.
>>>
>> When he said he thought the management was the same, he didn't mean the 
>> one
>> guy at the top was the same as last year.  He meant they share many
>> layers of management and very likely share many management products
>> like work processes and QA methods.
>
>The AVR is in the microcontroller division
>The AT91 is in the ASIC division
>The divisions do not share managers, but both report to the CEO and COO

Yes, the layer of management is what I meant.  
Maybe the new guy at the top will look deeper into the infrastructure
and into the QA and customer support.

Having said what I did about the customer support, I DO very much like
the basic architecture of the AVR parts.

Thanks guys,
boB

Ulf Samuelsson wrote:
>If you run in Thumb mode, you run full speed

I've heard this before but I don't understand it. Are you doing fetches
32 bits at a time in Thumb mode, and doing one 32 bit fetch for every
2, 16 bit opcodes? If so, then this is something like what the LPC MAM
is doing, right?

Is the LPC slower than the SAM7 in thumb mode? Is this related to the
faster underlying speed of the SAM flash (I understand your flash can
run at 30 Mhz, but the LPC flash can only run at 20 Mhz)?

>and since the SAM7 only has a single waitstate it should be faster than the LPC
>at any given frequency.

I understand that you're talking about thumb mode, but how can this be
faster than the LPC in thumb mode? I guess the LPC in inserting more
than 1 wait state in thumb mode? But aren' t they reading from flash in
chunks of 128 bits (using MAM) - that speedup should apply in both Arm
and Thumb modes, right?

You guys have brought up some new things that I didn't know about the
SAM7 devices and this is good information. I started looking at the
SAM7X last year, but it got delayed and my interest moved to the
Philips devices..

Regarding support issues, I contacted Atmel AT91 support several times
last year, and I got great answers. I also like at91.com (it has an
ugly look, but excellent content with knowledgeable users). And I
didn't have any luck with Philips tech support when I contacted them
this year. With the recent change to NXP this might be a good time to
"go back to the basics" and revisit my strategy.

The only support I can get for LPC is from the Yahoo forum. That's
pretty good, but its not something that's funded or endorsed by
Philips, and sometimes I wondor who's right when I see conflicting
message posts. At91.com is funded and endorsed by Atmel, if I
understand correctly.

The only minor gripe I have with Atmel is that they're very quiet when
it comes to their future plans. Philips used to "wow" us with early
news on upcoming devices. I'd like to see more info about what Atmel
has in the pipeline. We've got a long design and testing cycle so we
need to keep our eyes on the future.

Eric

"Eric" <englere_geo@yahoo.com> skrev i meddelandet 
news:1158954713.866614.278040@m7g2000cwm.googlegroups.com...
> Ulf Samuelsson wrote:
>>If you run in Thumb mode, you run full speed
>
> I've heard this before but I don't understand it. Are you doing fetches
> 32 bits at a time in Thumb mode, and doing one 32 bit fetch for every
> 2, 16 bit opcodes? If so, then this is something like what the LPC MAM
> is doing, right?
>

In Thumb mode, the CPU is fetching 16 bit instructions.
The memory controller is fetching 32 bits.

If the CPU jumps to 16 bit instruction 'n', it will take
two cycles to fetch n & n+1
When the CPU fetches n+1, the memory controller starts
fetching n+2 & n+3.
When the CPU fetches n+2, the memory controller is in the middle
of the access of n+2 & n+3 so the result can be immediately
forwarded to the CPU so this is also done with zero waitstates.

Jumps to odd locations will cause a waitstate in the second access.

> Is the LPC slower than the SAM7 in thumb mode? Is this related to the
> faster underlying speed of the SAM flash (I understand your flash can
> run at 30 Mhz, but the LPC flash can only run at 20 Mhz)?
>
>>and since the SAM7 only has a single waitstate it should be faster than 
>>the LPC
>>at any given frequency.
>
The SAM7 is faster than the LPC at 20-30 MHz since it is always zero 
waitstates
while the LPC adds some waitstates.

Whenever the chips jump to a new location, then LPC will have one more 
waitstate.
Whenever the chips fetch constants from flash, the LPC will have one more 
waitstate.

The LPC has a little higher clock frequency than the SAM7.
The main reason is that they use the ARM7TDMI-S
which is slightly faster than the ARM7TDMI.
S stands for synthesizable and while I have not seen the comparision for the 
ARM7,
I know that for the ARM9, this means about 30% higher power consumption.
I think I may have created my own problem here, since I badgered National 
Semiconductor
to license the ARM7TDMI (which they never used) and to demand a 
synthesizable version.
The ARM7TDMI was only available as a hard-core at the time...
Whenever Philips are on my back on performance (in ARM mode), I can sit back 
and
claim  that since they are using "my core" I am not surprised :-)

I think the LPC has some more advanced caching schemes than the SAM7,
which will increase its performance for very short loops.

It also has two banks, so if the CPU fetches data which is located
in the other bank, it can use the 128 bit line, but I doubt this is very 
useful
with the current set of compilers, since they tend to put data close to the 
instruction
which will then invalidate prefetch buffers.


If your application can copy to SRAM, then of course you do not have any 
waitstate
and the CPU. Often the SAM7 has more SRAM than the equivalent LPC
so there is some gains here.

You also have to think system performance. The AT91SAM7 peripherals help out 
a lot here.
What is the performance of an LPC when running a manchester coded serial 
protocol?
Since it does not support manchester coding, it will have to implement it in 
S/W.

Assume you want to write to a log in external serial flash.
The speed of the SPI is significantly faster in the SAM7 so you can complete 
the
job much faster (55 Mbps SPI in the latest chip)

Try running a couple of high speed serial lines, and the LPC is on the floor 
breathing for air,
and the SAM7 has not even worked up sweat due to the PDC.

If you really are after performance, the AT91SAM9261 will run 3-4 times the 
LPC
when executing out if its internal 160 kB SRAM at 200 MHz .
Have to boot from a small 1 Mbit dataflash, but otherwise they are similar 
to a SAM7
(if you can stnad the BGA package).  The new AT91SAM9260 will also be a 
killer chip.
Can't really see how you can design an ARM9 without Ethernet and LCD...

When I talk to customers about ARM, more than 60% are looking for ARM9
and most of those want embedded Linux. The AT91 rules there, (even with the 
LPC3 series)

> I understand that you're talking about thumb mode, but how can this be
> faster than the LPC in thumb mode? I guess the LPC in inserting more
> than 1 wait state in thumb mode? But aren' t they reading from flash in
> chunks of 128 bits (using MAM) - that speedup should apply in both Arm
> and Thumb modes, right?

(3 + 1 + 1 + 1 + 1 + 1 + 1+ 1)    >    (2 + 1 + 1 + 1 + 1 + 1 + 1+ 1)
Not by much, but if you add extra time for 1 more waitstate at each memory 
fetch
I think you will be slightly ahead.

> You guys have brought up some new things that I didn't know about the
> SAM7 devices and this is good information. I started looking at the
> SAM7X last year, but it got delayed and my interest moved to the
> Philips devices..
>
> Regarding support issues, I contacted Atmel AT91 support several times
> last year, and I got great answers. I also like at91.com (it has an
> ugly look, but excellent content with knowledgeable users). And I
> didn't have any luck with Philips tech support when I contacted them
> this year. With the recent change to NXP this might be a good time to
> "go back to the basics" and revisit my strategy.
>
> The only support I can get for LPC is from the Yahoo forum. That's
> pretty good, but its not something that's funded or endorsed by
> Philips, and sometimes I wondor who's right when I see conflicting
> message posts. At91.com is funded and endorsed by Atmel, if I
> understand correctly.

Yes

> The only minor gripe I have with Atmel is that they're very quiet when
> it comes to their future plans. Philips used to "wow" us with early
> news on upcoming devices. I'd like to see more info about what Atmel
> has in the pipeline. We've got a long design and testing cycle so we
> need to keep our eyes on the future.

Noone at Atmel wants to wow Philips.
They were out early with single chip flash parts and got a lot of things 
wrong.
The AT91SAM7 then came out, and in many respects, it is is right.
Cant complain, since I been badgering them about a lot of things implemented 
in the SAM7 :-)

Philips then went out and tried to copy a lot of things.
They are still way behind in peripherals though.

There are cool things planned (as well as bug fixes) but releasing early 
just means getting information to Philips.
Anyone checking out the datasheets of the AT91SAM9261 real closely might 
find some Easter Eggs






>
> Eric



-- 
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB