Single-Source PIC, AVR & Alternatives

rickman wrote:
> John Devereux wrote:
> > Unless the application is cost sensitive, nowadays I use an ARM7
> > variant for most things (e.g. LPC2000, AT91, ADUC7000, see
> > <http://www.gnuarm.com/ArmDevices_frame.html>.
> >
> > If it is cost sensitive, perhaps one of the low-end AVRs.
> >
> > All the above have good gcc support, and seem to be easily available
> > from e.g. Digikey.
>
> Heck, I recently had an AVR designed out in favor of an ARM7, initially
> because of the price advantage of the SAM7S64 vs. the ATmega128, but
> once we compared in detail the SAM7 also used less power at the same
> clock speed!
>
> I am surprised that no one else recommended an ARM.

I don't know, but I suppose many of us have applications that very low
sleep current, which ARM's don't have, or very fast wake up times,
which ARM's don't have, or wide operating voltages (e.g., 1.8 to 5
volts for AVR's) which ARM's don't have, or require integrated LCD
controllers to drive simple LCD glass, which ARM's don't have. PICs,
AVR's,MSP430s, H8's ,8051s, or Elans all have the above features in a
wide variety of flavors and tiny sizes.

The ARM is really a different class of embedded processor, higher
power, higher throughput, higher speeds, less integrated, requires
external regulators etc.

There is some overlap, with certain ARM's under certain conditions,  if
I remember correctly,  the SAM was the only ARM that beat the AVR in
active mode but that was only under certain strict conditions (no PLL),
the other ARM's had vastly greater power consumption (ADUC7000's for
example) making high active power another difference between ARM and
the gang I mentioned above.

Thus, although ARM's are nice, they don't cover the same range of
applications as the others,  it's nice to have one processor that you
can use when the power is provided by a coin cell or power mains.

Vladimir Vassilevsky wrote:

> cbarn24050@aol.com wrote:
>
> >
> > Rule 1. make sure you have enough parts in stock before designing them
> > in.
> > Rule 2. make sure you keep it that way once you go into production.
> >
>
> Those rules are not applicable unless your design is using only 7400s,
> LM358s, MAX232s and resistors of 10k. Even if it is so, there still may
> be the issues with ROHS compliance.
>
> Vladimir Vassilevsky
>
> DSP and Mixed Signal Design Consultant
>
> http://www.abvolt.com

I think you missed the point, its not the common parts you need to
stock.

steve wrote:
> rickman wrote:
> > John Devereux wrote:
> > > Unless the application is cost sensitive, nowadays I use an ARM7
> > > variant for most things (e.g. LPC2000, AT91, ADUC7000, see
> > > <http://www.gnuarm.com/ArmDevices_frame.html>.
> > >
> > > If it is cost sensitive, perhaps one of the low-end AVRs.
> > >
> > > All the above have good gcc support, and seem to be easily available
> > > from e.g. Digikey.
> >
> > Heck, I recently had an AVR designed out in favor of an ARM7, initially
> > because of the price advantage of the SAM7S64 vs. the ATmega128, but
> > once we compared in detail the SAM7 also used less power at the same
> > clock speed!
> >
> > I am surprised that no one else recommended an ARM.
>
> I don't know, but I suppose many of us have applications that very low
> sleep current, which ARM's don't have, or very fast wake up times,
> which ARM's don't have, or wide operating voltages (e.g., 1.8 to 5
> volts for AVR's) which ARM's don't have, or require integrated LCD
> controllers to drive simple LCD glass, which ARM's don't have. PICs,
> AVR's,MSP430s, H8's ,8051s, or Elans all have the above features in a
> wide variety of flavors and tiny sizes.
>
> The ARM is really a different class of embedded processor, higher
> power, higher throughput, higher speeds, less integrated, requires
> external regulators etc.
>
> There is some overlap, with certain ARM's under certain conditions,  if
> I remember correctly,  the SAM was the only ARM that beat the AVR in
> active mode but that was only under certain strict conditions (no PLL),
> the other ARM's had vastly greater power consumption (ADUC7000's for
> example) making high active power another difference between ARM and
> the gang I mentioned above.
>
> Thus, although ARM's are nice, they don't cover the same range of
> applications as the others,  it's nice to have one processor that you
> can use when the power is provided by a coin cell or power mains.

Some of what you say is true, but the apps where the wide voltage range
of the AVR is useful is only a subset of embedded apps.  It may be that
*all* of *your* apps fall in that category, but that still does not
mean that that is a large market compared to the rest.

When you talk about the SAM7 not beating the ARM other than under
"strict conditions", you may not understand the SAM7.  With the PLL on,
it is still lower power than the ATmega128 at the same clock speed.
The information I have from Atmel shows the current for the "clock
divisor" with the PLL on at under 300 uA or about three times the
current for the rest of the circuit running at just under 1 MHz.  With
the PLL off, the chip current can get below 40 uA at very low clock
speeds.  Meanwhile, the spread sheet shows the chip drawing 6 mA at
12.5 MHz with PIO, I2C and SPI all running.

The sleep current of the AVR will be lower than the SAM7, but that will
only be useful if your sleep ratio is higher than 99% of the time.
Also what you say about the "wake up" time of the ARM is not
universally valid.  For most apps you never have to put the CPU into
"sleep", you just slow down the clock with the divisor.  It all depends
on how deep you need to "sleep".

No, the ARMs of any flavor do not cover the same range as the low power
8 bit processors.  But there is a lot of overlap and the ARM is clearly
the better in those cases.  Part of the selection needs to consider
what your last design used (for reuse) and next design will require
(again for reuse).  For many of us, the ARM is the right answer based
on the need to provide more processing power in a small package with
low power.  Some still need the wide Vin range and ultra low sleep
current.

The parts I think will really kick some 8 bit butt is the next
generation of CM3 devices from LM.  I don't have any hard data yet, but
once they target the low power modes I think the CM3 has a lot of
potential to do low power "right"!  I just hope they don't give up 5
volt tolerance.

rickman wrote:
> steve wrote:
> > rickman wrote:
> > > John Devereux wrote:
> > > > Unless the application is cost sensitive, nowadays I use an ARM7
> > > > variant for most things (e.g. LPC2000, AT91, ADUC7000, see
> > > > <http://www.gnuarm.com/ArmDevices_frame.html>.
> > > >
> > > > If it is cost sensitive, perhaps one of the low-end AVRs.
> > > >
> > > > All the above have good gcc support, and seem to be easily available
> > > > from e.g. Digikey.
> > >
> > > Heck, I recently had an AVR designed out in favor of an ARM7, initially
> > > because of the price advantage of the SAM7S64 vs. the ATmega128, but
> > > once we compared in detail the SAM7 also used less power at the same
> > > clock speed!
> > >
> > > I am surprised that no one else recommended an ARM.
> >
> > I don't know, but I suppose many of us have applications that very low
> > sleep current, which ARM's don't have, or very fast wake up times,
> > which ARM's don't have, or wide operating voltages (e.g., 1.8 to 5
> > volts for AVR's) which ARM's don't have, or require integrated LCD
> > controllers to drive simple LCD glass, which ARM's don't have. PICs,
> > AVR's,MSP430s, H8's ,8051s, or Elans all have the above features in a
> > wide variety of flavors and tiny sizes.
> >
> > The ARM is really a different class of embedded processor, higher
> > power, higher throughput, higher speeds, less integrated, requires
> > external regulators etc.
> >
> > There is some overlap, with certain ARM's under certain conditions,  if
> > I remember correctly,  the SAM was the only ARM that beat the AVR in
> > active mode but that was only under certain strict conditions (no PLL),
> > the other ARM's had vastly greater power consumption (ADUC7000's for
> > example) making high active power another difference between ARM and
> > the gang I mentioned above.
> >
> > Thus, although ARM's are nice, they don't cover the same range of
> > applications as the others,  it's nice to have one processor that you
> > can use when the power is provided by a coin cell or power mains.
>
> Some of what you say is true, but the apps where the wide voltage range
> of the AVR is useful is only a subset of embedded apps.  It may be that
> *all* of *your* apps fall in that category, but that still does not
> mean that that is a large market compared to the rest.
>
> When you talk about the SAM7 not beating the ARM other than under
> "strict conditions", you may not understand the SAM7.  With the PLL on,
> it is still lower power than the ATmega128 at the same clock speed.
> The information I have from Atmel shows the current for the "clock
> divisor" with the PLL on at under 300 uA or about three times the
> current for the rest of the circuit running at just under 1 MHz.  With
> the PLL off, the chip current can get below 40 uA at very low clock
> speeds.  Meanwhile, the spread sheet shows the chip drawing 6 mA at
> 12.5 MHz with PIO, I2C and SPI all running.
>
> The sleep current of the AVR will be lower than the SAM7, but that will
> only be useful if your sleep ratio is higher than 99% of the time.
> Also what you say about the "wake up" time of the ARM is not
> universally valid.  For most apps you never have to put the CPU into
> "sleep", you just slow down the clock with the divisor.  It all depends
> on how deep you need to "sleep".
>
> No, the ARMs of any flavor do not cover the same range as the low power
> 8 bit processors.  But there is a lot of overlap and the ARM is clearly
> the better in those cases.  Part of the selection needs to consider
> what your last design used (for reuse) and next design will require
> (again for reuse).  For many of us, the ARM is the right answer based
> on the need to provide more processing power in a small package with
> low power.  Some still need the wide Vin range and ultra low sleep
> current.
>
> The parts I think will really kick some 8 bit butt is the next
> generation of CM3 devices from LM.  I don't have any hard data yet, but
> once they target the low power modes I think the CM3 has a lot of
> potential to do low power "right"!  I just hope they don't give up 5
> volt tolerance.


The new SAM7L series is claimed to be ultra low power and have LCD
drivers, which is the combo I need, but Atmel is also coming out with
Xmega AVR's series shortly (from the rumor mill), who knows what
features they will have.

steve wrote:
> The new SAM7L series is claimed to be ultra low power and have LCD
> drivers, which is the combo I need, but Atmel is also coming out with
> Xmega AVR's series shortly (from the rumor mill), who knows what
> features they will have.

Yes, but the term "ultra low power" has little real meaning just like
"pico power".  The pico power parts have low static current draw, but
that is only an issue in apps that have to remain in sleep mode for
more than 99% of the time.  Otherwise the SAM7 parts were designed for
very low active power and were made in a newer process than the AVRs,
so they get better power consumption.  I don't think the Xmega parts
are going to do any better.

Who knows what is going to be out tomorrow?  I am trying to get info
from LM on the next generation of CM3 parts.  Our stuff has to be low
power, but the uA of sleep current mean little.  It is the active
current that counts to us.  By this time next year I fully expect the
CM3 offerings to be dominating the new product announcements.

rickman wrote:

> steve wrote:
> 
>>The new SAM7L series is claimed to be ultra low power and have LCD
>>drivers, which is the combo I need, but Atmel is also coming out with
>>Xmega AVR's series shortly (from the rumor mill), who knows what
>>features they will have.
> 
> 
> Yes, but the term "ultra low power" has little real meaning just like
> "pico power".  The pico power parts have low static current draw, but
> that is only an issue in apps that have to remain in sleep mode for
> more than 99% of the time.  Otherwise the SAM7 parts were designed for
> very low active power and were made in a newer process than the AVRs,
> so they get better power consumption.  I don't think the Xmega parts
> are going to do any better.
> 
> Who knows what is going to be out tomorrow?  I am trying to get info
> from LM on the next generation of CM3 parts.  Our stuff has to be low
> power, but the uA of sleep current mean little.  It is the active
> current that counts to us.  By this time next year I fully expect the
> CM3 offerings to be dominating the new product announcements.

  Banking for 'new process' to deliver hoped for lower powers may be
optimistic. {vaporware can promise anything, it's real silicon that
counts )

  New process has not done this on FPGA, and if one looks at the newest 
200Mhz process devices from Atmel, you see these comments :


" The AT91SAM9263 consumes about 700 uA of static current on VDDCORE at 
25'C. This static current rises at up to 7 mA if the temperature 
increases to 85'C. On VDDBU, the current does not exceed 3 uA @25'C, but 
can rise at up to 20 uA @85'C.
  A software-controllable switch to VDDCORE guarantees zero power 
consumption on the battery when the system is on.
  For dynamic power consumption, the AT91SAM9263 consumes a maximum of 
70 mA on VDDCORE at maximum conditions (1.2V, 25�C, processor running 
full-performance algorithm)."

  Depends on your targets, but 700uA-7mA static are not leaps down in 
Icc in most designer's yardsticks (well, maybe if you come from a PC 
background ?! :)
  It does not matter HOW fancy your core is, or how fancy your clock 
gating, this static Icc is always there, until you remove the power 
entirely.
[This is why dual processor solutions are appearing, and why fewer are
expecting one chip to be the final solution ]


Marketing is still driven by MHz first, power 2nd (tho power is 
certainly now on the radar), and simple maths and physics are
still there...

Maybe this will be the solution, for those who still think in uA ?
http://www.eetimes.com/news/semi/showArticle.jhtml;jsessionid=MELRORG5M0GXMQSNDLRCKHSCJUNN2JVN?articleID=196602004

-jg

> The new SAM7L series is claimed to be ultra low power and have LCD
> drivers, which is the combo I need, but Atmel is also coming out with
> Xmega AVR's series shortly (from the rumor mill), who knows what
> features they will have.
>

I guess that, if the rumour mill is true, that would be me :-)

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

"rickman" <gnuarm@gmail.com> skrev i meddelandet 
news:1165869096.359955.303550@79g2000cws.googlegroups.com...
> steve wrote:
>> The new SAM7L series is claimed to be ultra low power and have LCD
>> drivers, which is the combo I need, but Atmel is also coming out with
>> Xmega AVR's series shortly (from the rumor mill), who knows what
>> features they will have.
>
> Yes, but the term "ultra low power" has little real meaning just like
> "pico power".  The pico power parts have low static current draw, but
> that is only an issue in apps that have to remain in sleep mode for
> more than 99% of the time.  Otherwise the SAM7 parts were designed for
> very low active power and were made in a newer process than the AVRs,
> so they get better power consumption.  I don't think the Xmega parts
> are going to do any better.
>


The Picopower has a power curve that starts at close to zero and increases
in almost a linear fashion.
The main advantage of Picopower is when you are in sleep mode
or are running at low clock frequencies.
When running at high frequency, the main benefit is from the new
cell library, which is not present in the ATmega128, that Rickman
compares with.

-- 
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:
> > The new SAM7L series is claimed to be ultra low power and have LCD
> > drivers, which is the combo I need, but Atmel is also coming out with
> > Xmega AVR's series shortly (from the rumor mill), who knows what
> > features they will have.
> >
>
> I guess that, if the rumour mill is true, that would be me :-)
>
No, I haven't seen any comments from you on xmega, unless you are using
different user names on different sites

steve wrote:
> Ulf Samuelsson wrote:
> 
>>>The new SAM7L series is claimed to be ultra low power and have LCD
>>>drivers, which is the combo I need, but Atmel is also coming out with
>>>Xmega AVR's series shortly (from the rumor mill), who knows what
>>>features they will have.
>>>
>>
>>I guess that, if the rumour mill is true, that would be me :-)
>>
> 
> No, I haven't seen any comments from you on xmega, unless you are using
> different user names on different sites

  I think Ulf was answering (strictly) the question
"Who knows what features they will have ?"
- hence the smiley...

  a better question would be "who is prepared to say what features
they will have?"  - if the rumour is true, of course.

  Seems there is always something new in the pipeline....


-jg