Maker Pro
Maker Pro

Single-Source PIC, AVR & Alternatives

T

Tim Wescott

Jan 1, 1970
0
Tim said:
I am currently working with a client who is designing a PIC
microprocessor into his system. It may be too late to change, but I am
being reminded of all the drawbacks to writing software for the PIC.

I heard from a committed PIC booster that "yes, the architecture sucks
for programming, but the PIC never has delivery problems". Choosing a
processor that my client couldn't get down the road would trump any pain
I may experience with less than beautiful code.

Does anyone have experience with alternatives to the PIC (and 8051
derivatives) that show that this is not a problem? The ones that come
to my mind the soonest are the AVR and the MSP430xxx lines, although I'm
sure that there are German and Japanese alternatives as well. The story
I heard about delivery problems was specifically about "Atmel doesn't
understand that it's single-source".

Thanks in advance.
This has been a really interesting thread to read, with all the opinions
and all.

But what I'm curious about is which companies have you had good
experiences with over the years, and which ones have left you feeling
like you'll never be dumb enough to design one of their parts into a
product ever again?

Thanks in advance.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
S

Spehro Pefhany

Jan 1, 1970
0
This has been a really interesting thread to read, with all the opinions
and all.

But what I'm curious about is which companies have you had good
experiences with over the years, and which ones have left you feeling
like you'll never be dumb enough to design one of their parts into a
product ever again?

Thanks in advance.

Some companies (Motorola, now Freescale) and Atmel have a history of
supplying large customers at the expense of smaller ones in times of
shortage. Microchip has a business strategy of keeping lead times
reasonable (stock to 4 weeks, IIRC). So far, they seem to be doing it.
Their customer base is also not as dependent on volatile sectors such
as automotive (Freescale) or cell phones (Atmel), AFAIUI.


Best regards,
Spehro Pefhany
 
H

Henry Kiefer

Jan 1, 1970
0
Tim Wescott said:
I understand that if I want to use a microprocessor with peripherals
that I'm saying goodby to second source. What I want is to know which
microprocessors companies have the best track records of taking care of
their single-sourced customers.

I never thought there is a un-answerable question. Here it is!

It depends simply on volume. If you are one of the big player you always
have a source - as long as you want.

Personally I look on the support and openess of information policy. That is
a good indication for later business relationship.


- Henry
 
H

Henry Kiefer

Jan 1, 1970
0
Tim Wescott said:
But what I'm curious about is which companies have you had good
experiences with over the years, and which ones have left you feeling
like you'll never be dumb enough to design one of their parts into a
product ever again?

If the company is mostly focused on one of the big markets, like automotive
or cell phones with short product lifecycles, there is a great change to run
into problems sometime later.

For propietary products Fujitsu is a no-go for me. And all the other
japanese/chinese too.


- Henry
 
M

maxfoo

Jan 1, 1970
0
I am currently working with a client who is designing a PIC
microprocessor into his system. It may be too late to change, but I am
being reminded of all the drawbacks to writing software for the PIC.

I heard from a committed PIC booster that "yes, the architecture sucks
for programming, but the PIC never has delivery problems". Choosing a
processor that my client couldn't get down the road would trump any pain
I may experience with less than beautiful code.

Does anyone have experience with alternatives to the PIC (and 8051
derivatives) that show that this is not a problem? The ones that come
to my mind the soonest are the AVR and the MSP430xxx lines, although I'm
sure that there are German and Japanese alternatives as well. The story
I heard about delivery problems was specifically about "Atmel doesn't
understand that it's single-source".

Thanks in advance.

If the client already uses the PIC, and you suggest another microcontroller.
Guess who gets the shaft if there are any problems...hehehe!
 
P

Paul Carpenter

Jan 1, 1970
0
On Saturday, in article
<[email protected]>
-- snip --

I understand that if I want to use a microprocessor with peripherals
that I'm saying goodby to second source. What I want is to know which
microprocessors companies have the best track records of taking care of
their single-sourced customers.

They are all companies, that just like us have finite resources, some have
different bias to sectors, there is *NO* magic solution (bar having the
complete raw materials silicon, gasses, metals to final product under
your own manufacturing control). The same as there is no magic technological
bullet that solves problems.

What ever company you deal with, will have problems at some time, even if
Microchip claim a 4week lead time at max, someone comes along and buys
most the stock of a particular part you want, will add a 4 week delay
if you hit that delay at the wrong time.

Some sectors like automotive, mean in a product lifecycle, you will still
be able to get the parts in 5 - 10 years time. I know of at least one
aviation sector project that has an obsolete part that they buy in as a
wafer, to then get packaged themselves, as the aircraft is still in
production!

If your volume is likely to be large talk early and often with your
distributor and manufacturer as this helps in production planning.
Who ever the manufacturer is.

My general rule is, when you are small volume try to ensure you have
product in your hand before laying out circuit, noting lead time and
ensuring you have parts in advance for at least the expected build
rate to cover lead time and review your requirements OFTEN.
 
V

Vladimir Vassilevsky

Jan 1, 1970
0
Tim said:
But what I'm curious about is which companies have you had good
experiences with over the years, and which ones have left you feeling
like you'll never be dumb enough to design one of their parts into a
product ever again?

I would keep myself from Maxim. They make awesome ICs and they are
really nice in providing the samples. However when it comes to the
production quantities, you are stuck for the unknown time period.

VLV
 
Tim said:
I am currently working with a client who is designing a PIC
microprocessor into his system. It may be too late to change, but I am
being reminded of all the drawbacks to writing software for the PIC.

I heard from a committed PIC booster that "yes, the architecture sucks
for programming, but the PIC never has delivery problems". Choosing a
processor that my client couldn't get down the road would trump any pain
I may experience with less than beautiful code.

Does anyone have experience with alternatives to the PIC (and 8051
derivatives) that show that this is not a problem? The ones that come
to my mind the soonest are the AVR and the MSP430xxx lines, although I'm
sure that there are German and Japanese alternatives as well. The story
I heard about delivery problems was specifically about "Atmel doesn't
understand that it's single-source".

Thanks in advance.

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

Spehro Pefhany

Jan 1, 1970
0
On Saturday, in article
<[email protected]>


They are all companies, that just like us have finite resources, some have
different bias to sectors, there is *NO* magic solution (bar having the
complete raw materials silicon, gasses, metals to final product under
your own manufacturing control). The same as there is no magic technological
bullet that solves problems.

What ever company you deal with, will have problems at some time, even if
Microchip claim a 4week lead time at max, someone comes along and buys
most the stock of a particular part you want, will add a 4 week delay
if you hit that delay at the wrong time.

OTOH, if Sanghe's policy is to build enough excess capacity ahead of
the curve, they are more likely to get there. Their costs will be
higher than if they aim to minimize capital expenses, but they may be
able to gain market share among customers who value availability. Make
sense? They can also *decide* not to take all the availability away
from the smaller customers when a large customer comes along and wants
an unexpectedly large quantity. ie. quote the big guy a bit longer
lead time and not screw the smaller guys. It's a business decision,
free will, not some free market crap. They can do whatever they like--
chips are not some fungible commodity.



Best regards,
Spehro Pefhany
 
V

Vladimir Vassilevsky

Jan 1, 1970
0
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
 
R

Rocky

Jan 1, 1970
0
Tim said:
I am currently working with a client who is designing a PIC
microprocessor into his system. It may be too late to change, but I am
being reminded of all the drawbacks to writing software for the PIC.

I heard from a committed PIC booster that "yes, the architecture sucks
for programming, but the PIC never has delivery problems". Choosing a
processor that my client couldn't get down the road would trump any pain
I may experience with less than beautiful code.

We have been using a PIC16C54 in a design for about 13 years. We really
should update to the 16F54 (it is slightly cheaper!), but we have not
had any problems getting the original part. From Microchip.

Rocky
 
T

Tim Wescott

Jan 1, 1970
0
Vladimir said:
I would keep myself from Maxim. They make awesome ICs and they are
really nice in providing the samples. However when it comes to the
production quantities, you are stuck for the unknown time period.

VLV

Yes, Maxim I already know about. I don't actually bear scars from their
policies*, but I do suffer some hearing loss from the cries of anguish
in neighboring cubes.

* I once sat in a room with a couple of Maxim sales guys who said "we
never obsolete parts". I think that's true -- they just don't start
turning the crank until they have 10000 on order.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google? See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
N

Nico Coesel

Jan 1, 1970
0
Tim Wescott said:
I am currently working with a client who is designing a PIC
microprocessor into his system. It may be too late to change, but I am
being reminded of all the drawbacks to writing software for the PIC.

I heard from a committed PIC booster that "yes, the architecture sucks
for programming, but the PIC never has delivery problems". Choosing a
processor that my client couldn't get down the road would trump any pain
I may experience with less than beautiful code.

Choosing a processor which can run 'standard' C code will make life a
lot easier in the long run (for example: when moving to a new CPU
after a few years).
Does anyone have experience with alternatives to the PIC (and 8051
derivatives) that show that this is not a problem? The ones that come
to my mind the soonest are the AVR and the MSP430xxx lines, although I'm
sure that there are German and Japanese alternatives as well. The story
I heard about delivery problems was specifically about "Atmel doesn't
understand that it's single-source".

Picking something that is carried by 'next day delivery companies'
(Digikey and Farnell to name a few) is usually safe. You can also look
at the STR7 series from SGS-Thompson.
 
M

maxfoo

Jan 1, 1970
0
I would keep myself from Maxim. They make awesome ICs and they are
really nice in providing the samples. However when it comes to the
production quantities, you are stuck for the unknown time period.

VLV

FedEx Truck Containing Maxim Parts Hijacked in Philippines

http://www.maxim-ic.com/company/hijackedparts/

Hope Fedex had a lojack installed in the truck.
 
H

Henry Kiefer

Jan 1, 1970
0
Tim Wescott said:
Yes, Maxim I already know about. I don't actually bear scars from their
policies*, but I do suffer some hearing loss from the cries of anguish
in neighboring cubes.

* I once sat in a room with a couple of Maxim sales guys who said "we
never obsolete parts". I think that's true -- they just don't start
turning the crank until they have 10000 on order.

Try MAX038 !

- Henry
 
J

John Devereux

Jan 1, 1970
0
Tim Wescott said:
I am currently working with a client who is designing a PIC
microprocessor into his system. It may be too late to change, but I
am being reminded of all the drawbacks to writing software for the
PIC.

I heard from a committed PIC booster that "yes, the architecture sucks
for programming, but the PIC never has delivery problems". Choosing a
processor that my client couldn't get down the road would trump any
pain I may experience with less than beautiful code.

Does anyone have experience with alternatives to the PIC (and 8051
derivatives) that show that this is not a problem? The ones that come
to my mind the soonest are the AVR and the MSP430xxx lines, although
I'm sure that there are German and Japanese alternatives as well. The
story I heard about delivery problems was specifically about "Atmel
doesn't understand that it's single-source".

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

rickman

Jan 1, 1970
0
John said:
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.
 
S

steve

Jan 1, 1970
0
rickman said:
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 said:
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.
 
R

rickman

Jan 1, 1970
0
steve said:
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.
 
Top