Prev: MSP430 and Linux
Next: 8051 problem with serial port and timer
From: Ulf Samuelsson on 17 Sep 2006 01:19
"Eric" <englere_geo(a)yahoo.com> skrev i meddelandet
news:1158461367.018532.249200(a)h48g2000cwc.googlegroups.com...
> 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

For now, a SAM7S16 is in design and is pin compatible with the S321/S32.

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

If you run in Thumb mode, you run full speed and since the SAM7 only has a
single waitstate,
it should be faster than the LPC at any given frequency.
If you know you run at low enough temp, you could test setting zero
waitstates at 48 MHz.
You could be surprised...

Also, if you have some communication tasks, then you find that the PDC will
off load the CPU significantly while the LPC gets bogged down.
Also, for some small compute intensive tasks, it is quite OK to copy and
execute
from SRAM, the SAM7 has plenty of that.


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

Then again, once you are deep in the project and try to solve the hard
problems
then you appreciate the SAM7 peripherals.

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

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

It depends on the conditions.
The PDC of the SAM parts allows you to do a lot while the CPU is sleeping.


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


From: Jim Granville on 17 Sep 2006 03:11
Ulf Samuelsson wrote:
> "Eric" <englere_geo(a)yahoo.com> skrev i meddelandet
> news:1158461367.018532.249200(a)h48g2000cwc.googlegroups.com...
>
>>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
>
>
> For now, a SAM7S16 is in design and is pin compatible with the S321/S32.
>
>
>>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.
>>
>>
>>>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.
>
>
> If you run in Thumb mode, you run full speed and since the SAM7 only has a
> single waitstate,
> it should be faster than the LPC at any given frequency.
> If you know you run at low enough temp, you could test setting zero
> waitstates at 48 MHz.
> You could be surprised...
>
> Also, if you have some communication tasks, then you find that the PDC will
> off load the CPU significantly while the LPC gets bogged down.
> Also, for some small compute intensive tasks, it is quite OK to copy and
> execute
> from SRAM, the SAM7 has plenty of that.

How much SRAM is in the SAM7S16 you mention ?

-jg

From: Ulf Samuelsson on 17 Sep 2006 11:54
>> Also, if you have some communication tasks, then you find that the PDC
>> will
>> off load the CPU significantly while the LPC gets bogged down.
>> Also, for some small compute intensive tasks, it is quite OK to copy and
>> execute
>> from SRAM, the SAM7 has plenty of that.
>
> How much SRAM is in the SAM7S16 you mention ?
>
> -jg

Not sure, 4-8kB so the idea of copying to SRAM is less useful for this chip.
With 64 kB SRAM in the AT91SAM7S256 it is a very good proposition.

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


From: Ulf Samuelsson on 19 Sep 2006 02:39
>>
>
> 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


From: boB on 19 Sep 2006 14:13
On Tue, 19 Sep 2006 08:39:07 +0200, "Ulf Samuelsson"
<ulf(a)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
>>

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: MSP430 and Linux
Next: 8051 problem with serial port and timer