What Bill said is another point. I just talked to a Microchip guy
and he mentioned this as well. As a matter of fact I just
complained to him about the pricing/delivery policy of Microchip.
They start to consider us a small customer with annual turnover
of half a million US$ (and will grow if we are happy with them).
They got very big customers in Singapore and ASEAN like Delphi
Automotive, Creative Technology and others.
Then I talked to the another colleague in another division, he
told me that we have major issues with Atmel due to EMC and other
performance problem. So for high reliability product, they are
now considering Microchip in the low end and Renesas in the high end.
AVR has slow AD conversion time of 65us-260us (ATtiny 26
datasheet pp77). Silabs C8051 is very good in this aspect.
We have also got a letter of assurance from them that
"In general, Silicon Laboratories, Inc. will not obsolete
the device if a customer is actively purchasing it in
quantities above l0k/year." That is not too bad. We will use
one of their product in a new design. But their price is
not so cheap.
The reason why Atmel is losing money may be due to what REB said
in his post. :) I wonder if they are just using their low cost
to lure customers and then obsolete all their MCUs in two years.
That will be a big trouble for us and a lot of others as well.
I do have my reservations about Microchip but I definitely has
more reservations about Atmel.
So maybe we have to go to another company? The low-pin count
Freescale MCU has too high current consumption (about 6mA
when using the built-in OSC) for me to use though. Their
pricing is now very good. The Microchip guy told me it is
because they write off a lot of their property and now
in a very good shape. I do not know it is true or not.
Motorola SPS used to be not a very friendly company.
What are your opinipns? I am talking about low cost families
(those below US$2.0 with 10k to 50k quantity).
>> IMHO, there are two strong disadvantages for the AVR family.
>>
>I'd feel warmer and fuzzier if Atmel were making money, too, instead
>of leaking red ink all over...
>
>Microchip and Freescale are credible "single source" manufacturers; I'm
>not so sure about atmel. Sigh.
>
>BillW
------
>Date: Wed, 24 Nov 2004 11:39:17 -0500
>From: "Roy E. Burrage" <.....RBurrageKILLspam@spam@bellsouth.net>
>
>And when Atmel obsoletes a product they replace it with one that will
>fit in the same hole but has more bells and whistles for less money,
>from my experience.
>
>REB
____________________________________________
>
>>> IMHO, there are two strong disadvantages for the AVR family.
>>>
>>I'd feel warmer and fuzzier if Atmel were making money, too, instead
>>of leaking red ink all over...
>>
>>Microchip and Freescale are credible "single source" manufacturers; I'm
>>not so sure about atmel. Sigh.
I must agree that I'd be more nervous about designing in Atmel than Microchip - Microchip have a
proven track record of good availability - they now even have a 'fab to order' test cell for rush
orders. They also don't obsolete parts, even when differences are tiny.
>>And when Atmel obsoletes a product they replace it with one that will
>>fit in the same hole but has more bells and whistles for less money,
>>from my experience.
But they also have a habit of introducing subtle changes that can take days to find & fix The newer
parts are rarely completely binary compatible - an important issue for product maintainance in a
market where the original programmer may have moved on.....
I had a cracker of a problem when upgrading to the Mega8515 recently....
The product started off on a 90S4414. When that was obsoleted we changed to the 90S8515 - no
problem.
However when _that_ one was obsoleted, we started seeing what apeared to be random eeprom failures
in the field.
We eventually found the problem - the 4414 has 256 bytes eeprom, so it has no EEADRH register, and
therefore no code to initialise it. The 8515 has 512 bytes, but EEADRH is initialised to 0 on reset,
so no problem- no code change needed. However on the Mega8515, this register is not initialised and
powers up in a random state. This was not highlighted in the 'differences' section of the datasheet.
Other people have had problems with significantly longer eeprom write times on the mega replacement
parts.
On Nov 25, 2004, at 12:43 AM, Chen Xiao Fan wrote:
> The reason why Atmel is losing money may be due to what REB said
> in his post. :) I wonder if they are just using their low cost
> to lure customers and then obsolete all their MCUs in two years.
>
I don't think microprocessors are enough of Atmel's market to contribute
much (one way or another) to their bottom line. They're losing money
cause they're trying to be a player in the nonvol memory market where
competition is WAY beyond "fierce." (I have not done the actual
business
analysis, though. Just guesses...)
Their "rapid phasing out" of products doesn't worry me TOO much; they
have been replaced by better products (in general) that are pretty
compatible. Not terribly different than microchip going from A to B
versions, and smaller than going from 16f to 18f families. I understand
this could be a problem for very large companies, but consider also that
Atmel doesn't have ROM or EPROM AVRs, so those companies weren't their
target market to start out with.
New Atmel products haven't had the excitement of the 10F PICs, or the
cleverness of the 16F54/etc, or even the niche-filling capability of
the MSP430. They seem a bit unfocused; like they originally decided
that they were going to introduce a processor line to compete directly
with PICs, only to have the PIC line get much bigger, and to get
distracted
by the "mega" possibilities that were outside their original target.
In some ways, it seems like a major benefit of the AVRs has been that
they've motivated microchip to make improvements along lines that they
might otherwise have neglected.
>
>Then I talked to the another colleague in another division, he
>told me that we have major issues with Atmel due to EMC and other
>performance problem. So for high reliability product, they are
>now considering Microchip in the low end and Renesas in the high end.
I would like to know more about this, I've not hit any issues of this nature.
>
>We eventually found the problem - the 4414 has 256 bytes eeprom, so it has
>no EEADRH register, and therefore no code to initialise it. The 8515 has
>512 bytes, but EEADRH is initialised to 0 on reset, so no problem- no code
>change needed. However on the Mega8515, this register is not initialised
>and powers up in a random state. This was not highlighted in the
>'differences' section of the datasheet.
This is why I try never to depend on a power up state.
I init everything, unless I am forced, by space requirements, to remove
that code.
I've done that for Zilog, 8051 variants, PIC, and Atmel.
Also, you'll hit another issue on early AVR parts, where X wasn't
implemented as a 16 bit register. You CAN still use it as two 8 bit
registers, but code written for the early parts will assume that XL will
never increment XH, which is no longer true, or they will use XL as a
pointer and XH to store other data, with somewhat bizarre results.
Still, pretty minor when jumping 8-10 years in processors.
>
>>
>> Then I talked to the another colleague in another division, he
>> told me that we have major issues with Atmel due to EMC and other
>> performance problem. So for high reliability product, they are
>> now considering Microchip in the low end and Renesas in the high end.
>
>
> I would like to know more about this, I've not hit any issues of this
> nature.
As would I. As an analog person who was forced into this digital
jun..er stuff, it seems that the only times I have had issues of this
sort were when I didn't use good design practices in the first place;
e.g. at 0300 you discover that the 100 pieces of a zero crossing triac
driver was actually 92, so you stuff a non zero crossing version into
the hole during test and then have intermittent craziness when a motor
starts. But this would also be an issue in almost any circuit. Atmel
also has a good app note addressing EMC which is pretty good, albeit
common sense.
EMC/RFI/EMI problems often get blamed on a chip when they are actually a
result of design practices in my experience. It doesn't make any
difference if the system is PLC, microcontroller, discrete logic, or any
other type we might want to name, the real world is noisy and we have to
compensate for it.
REB
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.289 / Virus Database: 265.4.2 - Release Date: 11/24/2004
The argument about MChip vs Atmel v MPS430 v Motorola really
comes down to a simple question- which uP vendor supports me 100%,
always has components, and has 10+ years of logical code progression?
There is only ONE vendor that meets all of these (my) needs, so I always
try my best to stick with 'em.
The fact that PICs consistently radiate less EMC is just a coincidental
advantage, not a deciding factor.
>
>>
>>We eventually found the problem - the 4414 has 256 bytes eeprom, so it has
>>no EEADRH register, and therefore no code to initialise it. The 8515 has
>>512 bytes, but EEADRH is initialised to 0 on reset, so no problem- no code
>>change needed. However on the Mega8515, this register is not initialised
>>and powers up in a random state. This was not highlighted in the
>>'differences' section of the datasheet.
>
>This is why I try never to depend on a power up state.
>I init everything, unless I am forced, by space requirements, to remove
>that code.
>I've done that for Zilog, 8051 variants, PIC, and Atmel.
Totally agree, BUT the kicker here is that the register that needed initialising DID NOT EXIST on
the chip that the code was originally written for.
As the 4414 to 8515 upgrade 'just worked', the customer didn't involve me at all - the Atmel guy
told them it was a drop-in replacement, they tried it and it worked.
It was only after the second obsolescence that this subtle issue manifested itself, in a
particularly nasty way, i.e. failures in the field. It was more by luck than anything else that I
spotted the difference and figured out what was happenning.
>
>Totally agree, BUT the kicker here is that the register that needed
>initialising DID NOT EXIST on
>the chip that the code was originally written for.
I hear ya.
They had to have reworked the int vector table though, and they SHOULD have
walked through the I/O inits and set anything they cared about. Apparently
they didn't.
I've also seen apps where they didn't completely populate the vector table,
which I also consider very dangerous. An accidentally enabled int that
happens, then warps you to hyperspace. I always populate them, at least
with RETI's and if I'm feeling paranoid, I put in the code to disable the
int, so if it is ever enabled, it gets turned back off when/if it
happens. Takes codespace though, and sometimes that's a problem.
>As the 4414 to 8515 upgrade 'just worked'
Danger will robinson!
>, the customer didn't involve me at all - the Atmel guy told them it was a
>drop-in replacement, they tried it and it worked.
>It was only after the second obsolescence that this subtle issue
>manifested itself, in a
>particularly nasty way, i.e. failures in the field. It was more by luck
>than anything else that I spotted the difference and figured out what was
>happenning.
Would have been more nasty if you didn't know it had been ported, but I
suspect a sim walkthrough would have shown it up.
Still much less painful than porting PIC apps between families.
:)
Matt, Thanks a lot! Your reply is very interesting and well written.
MSP430 is an interesting family and seems to catch up also. The problem
is always the pricing for us. It also seems to me that TI is basically
an Analog and DSP company and not so much an MCU vendor. We used their
TMS370 long ago and they are rare now.
Silicon Labs (Cygnal) parts are interesting too even though they are
not that big. So we have to wait and see.
Freescale is another reliable source but it seems now their lead
time is very long as well. It seems to me that Microchip and
Freescale are doing very well or too well.
Very interesting comments from Bill as well. Thanks.
>Date: Wed, 24 Nov 2004 16:10:12 -0600
>From: Matt Pobursky <.....piclistKILLspam.....mps-design.com>
>
>I always find this an interesting discussion.
>
>In my consulting business I basically use 3 microcontroller families
>for most of my small single chip applications: PIC, AVR and MSP430.
>
>Which one I choose is usually application driven:
>
>PICs for most 5V applications where power consumption is not a major
>concern. Microchip has a PIC with the exact mix of peripherals that
>match almost every application, one of the nice benefits of such a huge
>product line.
>
>AVR for some general purpose applications where the peripheral choice
>isn't real critical. Generally speedy operation and a great architecture.
>
>MSP430 for battery and low powered applications where power consumption
>is critical. Nothing touches the MSP430 for low power in the PIC or AVR
>line (although they are getting closer). MSP430 also has the best
>analog peripherals (12 bit ADCs and DACs that really are) of any micro
>family except maybe the Silicon Labs (Cygnal) parts.
>
>The MSP430 family is starting be a general purpose favorite of mine. TI
>are introducing new parts with higher clock rate and their peripheral
>modules are incredibly flexible, if not a bit complicated to understand
>at first. They also don't suffer from near the errata that seems to
>plague all new PIC chips these past few years. It appears sometimes
>that Microchip is taking the Microsoft approach to silicon design and
>requiring the users to be unpaid beta testers for new chip designs.
>Sometimes it takes more than a year for Microchip to correct errata on
>a give chip, I know of a PSP bug that I discovered in the 16C6x family
>and it took close to 2 years before they finally fixed it even though
>they went through at least two die shrinks over the same time period.
>Very frustrating.
>
>Atmel is second on my list of least trustworthy silicon suppliers
>(behind Maxim) due to their tendency to chase whatever market is hot at
>the moment. Someone also mentioned this in another post. I made a good
>living for about 18 months converting AVR apps to PIC when they decided
>to shut down AVR production in deference to Flash memory. They haven't
>added significant fab capacity since then, so I don't think it's out of
>the realm of possibility it could happen again. But for smaller volume
>projects where I can get all the parts I need "off-the-shelf", I think
>they're great.
>
>I have tools (C compiler/IDE/In-circuit Debugger/Programmer) for each
>family mentioned (as well as several other chip families) so I feel
>free to use whatever fits the application.
>
>One thing I'm always amazed at is how many people (even hobbyists) who
>STILL use the "churn 'n burn" method for debugging their firmware. I
>can understand this back in the days when hardware debugging required
>an expensive in-circuit emulator but those days are long gone. Every
>decent microcontroller family these days has in-circuit programming and
>debugging and usually a free or low cost tool chain to support it. If a
>micro doesn't have ISP and on-chip debugging I won't even consider it.
>I wouldn't consider it even if I was doing it as a hobby, especially
>when you can get an ICD2 (or equivalent) for the PICs or MSP430 FET pod
>so inexpensively.
>
>Matt Pobursky
>Maximum Performance Systems
>Date: Thu, 25 Nov 2004 03:48:02 -0800
>From: William "Chops" Westfield <EraseMEwestfwspam_OUTTakeThisOuTmac.com>
>...
>In some ways, it seems like a major benefit of the AVRs has been that
>they've motivated microchip to make improvements along lines that they
>might otherwise have neglected.
>
>BillW
I tend to agree with REB on the EMC things, especially when I was attending
the EMC seminars or reading some application notes. "The real world is noisy
and we have to compensate for it". However it is always easy said than done.
Engineering design are also always kind of trade-off between good design
practise and other issues like cost and space constraint.
A chip does played a part in this EMC aka black magic. The colleague told
me that they always put reset IC with Atmel and still often have problems
with current injection (IEC61000-4-6) test (the MCU reset or just go mad).
Some of our product have to comply with NAMUR NE21 standard for the chemical
industry and it is quite stringent in term of EMC. I consider our Germany
R&D teams to be very strong in analog design and follow good design
practise. In terms of software, I think they are also quite good as well.
They were not facing so much problems before using Atmel. Some of our
product only need to comply with EN60947-5-2 standard for proximity sensors
and things are not that bad and they use Atmel a lot due to the low cost
and popularity of Atmel in Europe. They do have issues with EMC too. In
this aspect, PICs are better. We do have some EMC problems with the new
PIC 16F device (/MCLR pin reset). Maybe die shrinking is to blame.
In the production, we also have more problems with the ISP with ATmel MCUs
(89C51 and the AVR) than PICs (ICSP) and maybe that is a separate issue.
That being said, our purchasing department is having major issues with
Microchip in terms of pricing and delivery policy. Maybe that is the
problem when they become No 1. So we do hope Atmel parts to be better
and better. :(
>Date: Thu, 25 Nov 2004 09:02:20 -0500
>From: "Roy E. Burrage" <RBurragespam_OUTbellsouth.net>
>
>>
>>>
>>> Then I talked to the another colleague in another division, he
>>> told me that we have major issues with Atmel due to EMC and other
>>> performance problem. So for high reliability product, they are
>>> now considering Microchip in the low end and Renesas in the high end.
>>
>> I would like to know more about this, I've not hit any issues of this
>> nature.
>As would I. As an analog person who was forced into this digital
>jun..er stuff, it seems that the only times I have had issues of this
>sort were when I didn't use good design practices in the first place;
>e.g. at 0300 you discover that the 100 pieces of a zero crossing triac
>driver was actually 92, so you stuff a non zero crossing version into
>the hole during test and then have intermittent craziness when a motor
>starts. But this would also be an issue in almost any circuit. Atmel
>also has a good app note addressing EMC which is pretty good, albeit
>common sense.
>
>EMC/RFI/EMI problems often get blamed on a chip when they are actually a
>result of design practices in my experience. It doesn't make any
>difference if the system is PLC, microcontroller, discrete logic, or any
>other type we might want to name, the real world is noisy and we have to
>compensate for it.
>
>REB
>Would have been more nasty if you didn't know it
>had been ported, but I suspect a sim walkthrough
>would have shown it up.
Haven't had occasion to use MPLAB 6.anything yet, but does the simulator
mark registers that get written to in a different colour, so you can see if
everything gets initialised?
On Fri, 26 Nov 2004 09:54:55 +0800, Chen Xiao Fan wrote:
> Matt, Thanks a lot! Your reply is very interesting and well written.
>
> MSP430 is an interesting family and seems to catch up also. The problem
> is always the pricing for us. It also seems to me that TI is basically
> an Analog and DSP company and not so much an MCU vendor. We used their
> TMS370 long ago and they are rare now.
I was very skeptical about using the MSP430 family, even after
attending one of TI's excellent MSP430 seminars a few years ago.
However, I did receive one of their starter kits at the seminar and
gave it a go. I was very very impressed by the processing power vs.
power consumption and put them on my "radar", waiting to see how 3rd
party development tool support would develop and whether TI would
support this family better than the TMS370 (which was pathetic at
best!).
After probably six months time, I had a client approach me about adding
several features to an existing design that was based on the PIC16C92x
family. It was a battery powered industrial meter and was out of
program space. It also had less than desired battery life. So I re-
evaluated the MSP430 family and we decided to port the design to the
MSP430F43x chip.
The design port went very smoothly. The hardware portion was done in
about 2 weeks and the software (including additional features) took
about another two weeks (the PIC code was written in C and easy to
port). The result was we now had a CPU that was flash based rather than
OTP, had twice the battery life than with the PIC design and we also
had more than twice the RAM and still had over 16K of program space
available for future software additions (which have since been made).
The CPU cost was within pennies of each other and as an additional
benefit, we eliminated several other support components with the TI
chip (A/D reference being the major component).
I've found the chips (PIC/AVR/MSP430) to all be cost competitive in
similar volumes and features. TI and Microchip have excellent sampling
and availability (at least here in the U.S.). The contract
manufacturers that produce most of the products I design have said TI
pricing and availability has been good for them also. I've also
received excellent technical support from the TI design center in
Dallas and from the local TI sales representative.
>On Fri, 26 Nov 2004 09:54:55 +0800, Chen Xiao Fan wrote:
>
>
>> Matt, Thanks a lot! Your reply is very interesting and well written.
>>
>> MSP430 is an interesting family and seems to catch up also. The problem
>> is always the pricing for us. It also seems to me that TI is basically
>> an Analog and DSP company and not so much an MCU vendor. We used their
>> TMS370 long ago and they are rare now.
>>
>>
>
>I was very skeptical about using the MSP430 family, even after
>attending one of TI's excellent MSP430 seminars a few years ago.
>However, I did receive one of their starter kits at the seminar and
>gave it a go. I was very very impressed by the processing power vs.
>power consumption and put them on my "radar", waiting to see how 3rd
>party development tool support would develop and whether TI would
>support this family better than the TMS370 (which was pathetic at
>best!).
>
>After probably six months time, I had a client approach me about adding
>several features to an existing design that was based on the PIC16C92x
>family. It was a battery powered industrial meter and was out of
>program space. It also had less than desired battery life. So I re-
>evaluated the MSP430 family and we decided to port the design to the
>MSP430F43x chip.
>
>The design port went very smoothly. The hardware portion was done in
>about 2 weeks and the software (including additional features) took
>about another two weeks (the PIC code was written in C and easy to
>port). The result was we now had a CPU that was flash based rather than
>OTP, had twice the battery life than with the PIC design and we also
>had more than twice the RAM and still had over 16K of program space
>available for future software additions (which have since been made).
>The CPU cost was within pennies of each other and as an additional
>benefit, we eliminated several other support components with the TI
>chip (A/D reference being the major component).
>
>I've found the chips (PIC/AVR/MSP430) to all be cost competitive in
>similar volumes and features. TI and Microchip have excellent sampling
>and availability (at least here in the U.S.). The contract
>manufacturers that produce most of the products I design have said TI
>pricing and availability has been good for them also. I've also
>received excellent technical support from the TI design center in
>Dallas and from the local TI sales representative.
>
>Matt Pobursky
>Maximum Performance Systems
>
>What other microprocessor manufactures compete against PIC & Atmel?
>
>Does Texas Instruments have similar chips?
Not really. SGS-Thomson and Motorola, sorry, Freescale are in similar market areas but neither has a
good track record on availability to low-volume users, and devtools are not at the same level as MCT
and Atmel - last time I used ST7 the toolchain was a real mess.
Hitachi, sorry, Renesas have recently introduced cut-down versions of their H8 but I can't really
see these getting anyhere - Atmel and Microchip have too much of a head start.
>I personally would only be interested in chips that are supplied as DIL
>packages at this stage.
I was talking to an Atmel guy at a seminar recently. He was confident that the end is definitely in
sight for DIL. This will be accelerated by the move to lead-free parts - some leadframe suppliers
have said they are not going to bother with DIL when they move to lead-free.
>
>I was talking to an Atmel guy at a seminar recently. He was confident that
>the end is definitely in sight for DIL. This will be accelerated by the
>move to lead-free parts - some leadframe suppliers have said they are not
>going to bother with DIL when they move to lead-free.
Well, prototyping is going to get interesting, unless you can do carrier
boards.
On Sat, 27 Nov 2004 09:46:48 +1300, Hopkins wrote:
> What other microprocessor manufactures compete against PIC & Atmel?
>
> Does Texas Instruments have similar chips?
>
> I personally would only be interested in chips that are supplied as DIL
> packages at this stage.
>
> I am also looking to see who has the easiest way of setting up a
> reliable programming environment at low cost.
Well the MSP430 chips have a bit of a different design philosophy than
most general purpose microcontrollers. They are really optimized for
"burst mode" processing, i.e. idle along in sleep or 32Khz mode and
wakeup with external events to do quick work of the event then go back
to sleep/idle mode. This keeps the average power way down. So it takes
a bit of re-thinking the design process vs. how you'd normally do a PIC
or AVR design if you want to truly minimize power consumption. Of
course the MSP430 can be run at full speed continually like a PIC or
AVR typically is, but with higher average power.
The "MSP" stands for Mixed Signal Processor and TI has really geared these devices for just that. They have very good analog peripherals on them vs. most other microcontrollers. Their ADC and DAC circuits are
quite good -- I routinely get 11+ bits of usable range (i.e. 1 lsb of
"bounce" or less) from their ADC12 module (good PCB layout is a must
though). They have some cool options for DMA on the ADC and DAC
circuits which allow analog data I/O while the CPU sleeps! Lots of
timer/capture options and a lot of the chips can have 4 or more
independent PWM outputs. Most of the midrange up parts have 2 UARTS,
the UARTS can be clocked from the 32KHz clock while the CPU sleeps and
continue to receive data -- something very difficult, if not impossible
to do with a PIC.
Sadly for you, they only make them in surface mount packages. I don't
mind this and in fact haven't done a commercial design with a DIP
microcontroller since 1998. I actually find SMD to be much more
convenient for me -- yes, even prototyping. I do it all in SMD now.
For those who can't deal with the SMD aspect of the MSP430, Olimex
makes some nice header boards with the MSP430s already soldered and
with .1" centered pins. You can order them direct from Olimex or from http://www.sparkfun.com.
The cheapest programming setup for the MSP430 would be an Olimex FET JTAG pod and your target board. Total cost ~$10 US. I've found it very
reliable under Win9x or Win2K. You can use the IDE programmer software
from your toolset or in my case the tool vendor (Quadravox) has command
line programming software that can be called from a PC application.
That's what I use, even for most of my production units. For those who
need "better" programmers there are several 3rd party production
programmers and I believe TI sells one also.
On Fri, 26 Nov 2004 22:37:00 +0000, Mike Harrison wrote:
> On Sat, 27 Nov 2004 09:46:48 +1300, you wrote:
>
> >What other microprocessor manufactures compete against PIC & Atmel?
> >
> >Does Texas Instruments have similar chips?
>
> Not really. SGS-Thomson and Motorola, sorry, Freescale are in similar
> market areas but neither has a good track record on availability to
> low-volume users, and devtools are not at the same level as MCT and
> Atmel - last time I used ST7 the toolchain was a real mess. Hitachi,
> sorry, Renesas have recently introduced cut-down versions of their H8
> but I can't really see these getting anyhere - Atmel and Microchip
> have too much of a head start.
I've had really good experience with all the TI 3rd party tools I've used (IAR, Quadravox, Imagecraft, Rowley). They all are professional level, produce good code and have good support. They all program and debug chips flawlessly for me. Of all the chip families, I like the MSP430 tools best and would choose them all things being equal. The TI
JTAG interface just works a lot better and is much more convenient to
use than the Microchip ICSP interface. Don't get me wrong, I'm happy to
have the ICSP on Microchip parts but it has warts the TI interface
doesn't.
Of course, I'm a Microchip consultant and will continue to do a significant number of PIC designs. I do find a lot of annoying problems
with their tools and have pretty much stopped using MPLAB because of them. In case you're wondering -- I use CCS PCWH compiler/IDE/debugger and ICD-S40 or ICD-U40 which I think runs circles around MPLAB and ICD2 (especially for C source level debugging, which is what I'm most interested in). I have an ICD2 and MPLAB, I just don't use them often
anymore.
My preference for development environment/tools based on MPU family is:
1) MSP430
2) AVR
3) PIC
Any of the others are also-rans... I agree with you there. I'd consider
them, but only if one of the above wasn't suitable.
> >I personally would only be interested in chips that are supplied as DIL
> >packages at this stage.
>
> I was talking to an Atmel guy at a seminar recently. He was confident
> that the end is definitely in sight for DIL. This will be accelerated
> by the move to lead-free parts - some leadframe suppliers have said
> they are not going to bother with DIL when they move to lead-free.
Yep. Other than hobbyists, DIL is pretty much dead already. Every time
I go to a contract manufacturer facility I look around at the boards
they are producing. It's getting to be a rare sight to see any DIP
package of any kind, unless the design is more than 5 years old.
>
>>
>>I was talking to an Atmel guy at a seminar recently. He was confident that
>>the end is definitely in sight for DIL. This will be accelerated by the
>>move to lead-free parts - some leadframe suppliers have said they are not
>>going to bother with DIL when they move to lead-free.
>
>Well, prototyping is going to get interesting, unless you can do carrier
>boards.
Not a major problem really, until you start getting to the silly stuff like BGAs, and certainly not
a factor that would have any influence at all on a manufacturers' decision on whether or not to
continue making DILs.
The increasing use of in-circuit programming and on-chip debuggers like Microchip ICD and Atmel
Jtag-Ice means that there is a lot less need to be able to unplug chips even on prototype boards.
>On Sat, 27 Nov 2004 09:46:48 +1300, Hopkins wrote:
>> What other microprocessor manufactures compete against PIC & Atmel?
>>
>> Does Texas Instruments have similar chips?
>>
>> I personally would only be interested in chips that are supplied as DIL
>> packages at this stage.
>>
>> I am also looking to see who has the easiest way of setting up a
>> reliable programming environment at low cost.
>
>Well the MSP430 chips have a bit of a different design philosophy than
>most general purpose microcontrollers. They are really optimized for
>"burst mode" processing, i.e. idle along in sleep or 32Khz mode and
>wakeup with external events to do quick work of the event then go back
>to sleep/idle mode. This keeps the average power way down. So it takes
>a bit of re-thinking the design process vs. how you'd normally do a PIC
>or AVR design if you want to truly minimize power consumption. Of
>course the MSP430 can be run at full speed continually like a PIC or
>AVR typically is, but with higher average power.
Microchip can now do this sort of thing with their 'nanowatt' parts, which have a variety of
interesting clock-switching possibilities, including ISTR a 2uA WDT with a BIG prescaler.
>Microchip can now do this sort of thing with their 'nanowatt' parts, which
>have a variety of
>interesting clock-switching possibilities, including ISTR a 2uA WDT with
>a BIG prescaler.
The AVRs have the ability to run from a 32kHz watch crystal, and to
prescale the main clock by a value from 1 to 128 (77, or 36, or whatever)
loaded in a register.
> What other microprocessor manufactures compete against PIC & Atmel?
Motorola, TI, Ubicom, Cypress, fairchild (has anyone actually USED an
ACE?)
and a whole slew of 8051s (philips being the big "small" microcontroller
vendor in the 8051 space, along with Atmel.)
> Does Texas Instruments have similar chips?
>
> I personally would only be interested in chips that are supplied as DIL
> packages at this stage.
>
Unfortunately, that eliminates quite a few of them. Mot and cypress
have a fair selection of DIPs. Philips has a few (recent (and welcome)
additions, I think...) in their LPC700 line. TI's MSP430 has NO DIP
parts :-(
>Unfortunately, that eliminates quite a few of them. Mot and cypress
>have a fair selection of DIPs. Philips has a few (recent (and welcome)
>additions, I think...) in their LPC700 line. TI's MSP430 has NO DIP
>parts :-(
>
>BillW
DIP is like Octal base. They still work, but it's time to move to the
Compactrons for most work.
Sometimes attempting to take all of the "extraneous costs" out of a
product will come back and bite us. Admittedly, we don't do production
quantities here anywhere near the level of most manufacturers, but we
would rather spend a few cents or even a few dollars to have a more
bullet proof product...no matter what the technology being used. It
costs a lot of money to send a technician or an engineer to the field to
correct a problem. The cost is less to have equipment shipped back to
our shop, but sometimes even that is not an option. Even with a good
warranty program in place, if the equipment is constantly failing the
customer is going to wonder what is going on. Can we spell
Hewlett-Packard, now Agilent? I have an old HP 204C signal generator
that I bought used 25 years ago, and it works as well today (well,
yesterday) as it did when I bought it.
One example is a customer who had us making control modules for him,
used in commercial laundry equipment. Initially everything was
wonderful and the modules lasted a long time in the field. Then we all
of a sudden began receiving a lot of warranty returns. With some
investigation we discovered that the problems were only occurring after
a certain serial number of their machines. When I asked their project
engineer if he was using snubbers and anti parallel diodes across all of
his relays (the failure mode was indicative of transients on the supply
lines) his response was "Ummmm..." so we decided that I needed to go see
what was up with the newer machines. After several hours we discovered
some transients occurring when a 24 VDC clutch/brake operated. More
equipment. We found that when that 24 volt, 1 amp, clutch/brake
operated it was putting a transient on the power supply line of
something greater than 1,000 volts. That's all we could see on the
scope with a 100:1 probe and the vertical attenuator maxed out...and it
was several microseconds wide. A 1N4936 diode (about $0.27 at that
time) fixed the problem on that $40K machine and we had no more failures.
As far as the AVRs being more noise sensitive, I haven't seen that to be
a problem. A few years ago we did a production line test system for a
customer right up the road from us. I designed the board to use a reset
IC just in case, and since this was my first AVR project for a customer,
but we never had to use it. I do, however, put an RC on the reset pin
no matter what the project is. I like to use a 10K with a 1uf or a 10uf
cap right at the pin.
I also like to use some Rs anc Cs on the inputs, perhaps a carryover
from back in the days when debouncing had to be done discretely and
those ICs available to perform that function were expensive. On digital
inputs I use a 1K to V+ and a 0.1uF to ground with a 10K in series with
the input pin of the controller, schematic attached, and have had very
few problems over the years. Resnets aren't expensive these days.
Actually, in the project above we knew that once we showed the big guys
how well the initial version worked and explained how much more we could
do by automating their production test in this manner we would be doing
further upgrades so I intentionally used some very poor design practices
that could be easily corrected just for Ss and Gs. I ran switch input
wires close to relays and solenoids. I ran signal wires in the same
bundle as power wiring, but did use shielded cables. The board is
mounted within 6 inches of 4, 12 volt, 1/2 amp, solenoids...they
actually encircle the board. And then there are the gas
igniters...there is an igniter module about 6 inches from our control
board. There is also one in each device being tested as it goes down
the production line. The only problems we've had with this control have
been the igniter transients (each pulse from the igniter can be as much
as several hundred amps from what I have been told) popping the tops off
of my power MOSFETs in the power section, thereby letting all of the
smoke out of them, during the early stages of the project. The original
uses a 2313, which is currently being upgraded to a Mega16.
I would think that shrinking the die would actually improve noise
susceptibility. Shorter traces make for fewer antennae. Some of us
Blue Hairs can remember the system simplification when transistors and
ICs became reliable enough to replace vacuum tubes and their attendent
discrete wiring. Again, fewer antennae. But NASA and the space program
serve no useful purpose...
Could part of their problem be board layout? We lay out boards by hand,
still, because the autorouter in our CAD package wants to throw things
all over the place and it would still require significant hand routing
to do nice things like making star grounds and separating analog and
digital sections, including power supplies which will at least be routed
separately even if we don't use a separate regulator.
>I tend to agree with REB on the EMC things, especially when I was attending
>the EMC seminars or reading some application notes. "The real world is noisy
>and we have to compensate for it". However it is always easy said than done.
>Engineering design are also always kind of trade-off between good design
>practise and other issues like cost and space constraint.
>
>A chip does played a part in this EMC aka black magic. The colleague told
>me that they always put reset IC with Atmel and still often have problems
>with current injection (IEC61000-4-6) test (the MCU reset or just go mad).
>Some of our product have to comply with NAMUR NE21 standard for the chemical
>industry and it is quite stringent in term of EMC. I consider our Germany
>R&D teams to be very strong in analog design and follow good design
>practise. In terms of software, I think they are also quite good as well.
>They were not facing so much problems before using Atmel. Some of our
>product only need to comply with EN60947-5-2 standard for proximity sensors
>and things are not that bad and they use Atmel a lot due to the low cost
>and popularity of Atmel in Europe. They do have issues with EMC too. In
>this aspect, PICs are better. We do have some EMC problems with the new
>PIC 16F device (/MCLR pin reset). Maybe die shrinking is to blame.
>
>In the production, we also have more problems with the ISP with ATmel MCUs
>(89C51 and the AVR) than PICs (ICSP) and maybe that is a separate issue.
>
>That being said, our purchasing department is having major issues with
>Microchip in terms of pricing and delivery policy. Maybe that is the
>problem when they become No 1. So we do hope Atmel parts to be better
>and better. :(
>
>Xiaofan
>
>
>
>>Date: Thu, 25 Nov 2004 09:02:20 -0500
>>From: "Roy E. Burrage" <KILLspamRBurrageKILLspambellsouth.net>
>>
>>
>>
>>>>Then I talked to the another colleague in another division, he
>>>>told me that we have major issues with Atmel due to EMC and other
>>>>performance problem. So for high reliability product, they are
>>>>now considering Microchip in the low end and Renesas in the high end.
>>>>
>>>>
>>>I would like to know more about this, I've not hit any issues of this
>>>nature.
>>>
>At 06:56 PM 11/26/2004, Mike Harrison wrote:
>
>>Microchip can now do this sort of thing with their 'nanowatt' parts, which
>>have a variety of
>>interesting clock-switching possibilities, including ISTR a 2uA WDT with
>>a BIG prescaler.
>
>The AVRs have the ability to run from a 32kHz watch crystal, and to
>prescale the main clock by a value from 1 to 128 (77, or 36, or whatever)
>loaded in a register.
>> DIP is like Octal base. They still work, but it's time to move to the
>> Compactrons for most work.
>
> I will sorely miss sockets (reasonably priced sockets.)
I'm looking into buying a hot air rework station. I've never worked with
one, but it seems that this might make exchanging SMD parts almost as easy
as if they were socketed.
Has anybody experience with those stations? Are my expectations close to
reality?
Gerhard
____________________________________________
>
> >The AVRs have the ability to run from a 32kHz watch crystal, and to
> >prescale the main clock by a value from 1 to 128 (77, or 36, or whatever)
> >loaded in a register.
>
>Which AVRs can do that...?
M128, and I would expect the M256 as well, Look for the Xdiv register in
the data sheet.
I just bought one. Only E 150, but I added some more nozzeles at E 30 a
piece. Works like a charm, but takes a few minutes to warm up and also
to cool down.
> Are my expectations close to reality?
Depends on what your expectations are :)
Removing a TSOP chip is easy. I throw the chip away, but the PCB is
still usable. Use solder wick to remove the solder, otherwise the new
chip won't fit.
Wouter van Ooijen
-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu
I've been dabbling in TI's MSP430 series, and Freescale's M68hc series.
Between the two, the TI wins by a lot for my hobbyist oriented projects. I
love all the extra 16-bit registers and the many available boot-up modes.
They are both von-neumann architectures, as opposed to the PICs harvard
architecture. Apparently this has to do with the way the peripherals are
mapped onto the data buses, though I don't really understand it all yet
(thats why I'm playing with them).
The down side to the TI chips is that they are not available in DIL
packaging, but I've found the SOIC chips to be pretty easy to solder onto a
breakout board, or there are "pre-soldered" breakout boards available from
Olimex and other sources for ~$7, which are great for breadboard prototypes.
The TI sample service is quite good, as well (always a plus in my book).
The GREAT thing about the TI chips is the full GNU tools available. There
aren't many *great* tutorials on how to get started with them, but if you
have any experience using GCC the learning curve is pretty mild. The
standard JTAG programmer is $9, along with a $7 development board and you're
ready to get started with a great low-power von-neumann uP for under US $20.
TI also provides a good free assembler if you like that route, similar to
MPLab, which also compiles up to 2k of C-code.
----- Original Message -----
From: "Matt Pobursky" <spamBeGonepiclistspamBeGonemps-design.com>
<snip>
You can use the IDE programmer software
from your toolset or in my case the tool vendor (Quadravox) has command
line programming software that can be called from a PC application.
That's what I use, even for most of my production units. For those who
need "better" programmers there are several 3rd party production
programmers and I believe TI sells one also.
<snip>
You forgot to mention my favorite one, the open-source GDB and/or
msp430-jtag tools. It's proven quite reliable in the programming I've done,
and after a little work setting up a shell script to automate the process
it's relatively painless.
example:
make
msp430-jtag -e
msp430-jtag -i file.hex
The great thing about this is it's free, well supported, and works the same
on all my computers regardless of OS. Plus it supports the full range of
GDB imbedded debugging commands.
I looked into purchasing a hot air rework station as well, but found that
for most hobby-type work (which is all I ever do), a Pyro-Pen Junior works
very well. It has a "hot air blow" attachment, which heats air with the
butane flame and blows hot air out the tip. It works great with some solder
paste for soldering SOIC parts, but I haven't tried anything smaller yet.
If you go this road be wary of cheaper alternatives, as many of them have a
"solder" tip and a "blowtorch" tip, neither which are effective at soldering
SMD onto circuit boards. If it doesn't explicitly say "hot air blow" or
equivalent, then pass on it for SMD work. I tried using a standard butane
pencil when I first heard about this, and it just fried the chip and carrier
board.
> William ChopsWestfield wrote:
>
>>> DIP is like Octal base. They still work, but it's time to move to the
>>> Compactrons for most work.
>>
>> I will sorely miss sockets (reasonably priced sockets.)
>
> I'm looking into buying a hot air rework station. I've never worked with
> one, but it seems that this might make exchanging SMD parts almost as easy
> as if they were socketed.
> Has anybody experience with those stations? Are my expectations close to
> reality?
Yes, after some practice, and it does not work with all boards. I have
used tools by Hakko. As always, new tools from any reputable company are
good. Ask me after 10 years which I'd like to buy again ;-)
Peter
____________________________________________
Top 20 8-bit MCU vendors according to unit shipment
1. Microchip
2. Motorola Now Freescale
3. ST
4. NEC
5. Atmel
6. Sunplus Taiwan http://www.sunplus.com.tw
7. Hitachi Now part of Renesas
8. Fujitsu
9. Philips
10. Toshiba
11. Mitsubishi Now part of Renesas
12. Samsung
13. Elan Taiwan http://www.emc.com.tw
14. Winbond Taiwan http://www.winbond.com
15. Zilog
16. Sanyo
17. Matsubishita
18. Infineon
19. Holtek Taiwan http://www.holtek.com
20. National Semi
Out of the first 20 companies, Ubicom and Silabs (Cygnal)
seems to have some interesting parts as well. I heard of
ACE but only heard of. :) I found my company is now using
company 1,2,3,4,5,8,9,11,15,18 with Microchip and Atmel
being the more preferred vendor.
The people here should be quite family with them except
the Taiwanese companies. They are normally in the high volume
consumer electronics products produced in the Great China
region (Mainland China, Hong Kong SAR, Macau SAR and Taiwan).
SAR stands for special administration region or similar.
Xiaofan
>Date: Fri, 26 Nov 2004 22:06:10 -0800
>From: William "Chops" Westfield <RemoveMEwestfwTakeThisOuTmac.com>
>> What other microprocessor manufactures compete against PIC & Atmel?
>
>Motorola, TI, Ubicom, Cypress, fairchild (has anyone actually USED an
>ACE?)and a whole slew of 8051s (philips being the big "small"
microcontroller
>vendor in the 8051 space, along with Atmel.)
>
>BillW
____________________________________________
You do realize that the top 20 list does not distinguish between
Companies that only manufacture microcontrollers and companies that
manufacture and use its own microcontrollers in its products. Motorola
is a very good example.
Oh yes. However Freescale does have an advantage over Microchip because
it is a much larger company and more resources.
Another interesting phenomena is that people tend to prefer to use the
parts from the same geographic region.
The Taiwanese company product is only popular in the Great China Region.
In Europe, people tend to use European company product. Atmel is half
European (Temic). Japanese companies like to use parts from Japanese
companies.
For me I would not recommend Japanese and Taiwanese MCU vendors because of
lack of quality documentation in general. US companies are the best in
this aspect. Maybe this is because of the language barrier.
Xiaofan
>Date: Mon, 29 Nov 2004 11:23:45 +0200
>From: "Adlam Frank" <FADLAMEraseME.....petech.ac.za>
>
>You do realize that the top 20 list does not distinguish between
>Companies that only manufacture microcontrollers and companies that
>manufacture and use its own microcontrollers in its products. Motorola
>is a very good example.
>Oh yes. However Freescale does have an advantage over Microchip because
>it is a much larger company and more resources.
Big companies are more detached from their less-than-similarly big customers. Once they stop selling
zillions of a part they don't care if discontinuing it leaves you up the preverbial creek without a
paddle. When, e.g. Ford decide they want a few 100K of a part, guess who goes to the back of a
queue.
Microchip have always appreciated their smaller customers, and have never had any major leadtime
problems on any released part. The same cannot be said for any other major MCU supplier that I'm
aware of.
I'm willing to bet that there are more people who regret designing in Motorola etc. than Microchip,
Size isn't everything, and can often be a major disadvantage.
@spam@bellsouth.net>
