Single-Source PIC, AVR & Alternatives

[Tim Wescott]

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.

--

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

 

[Henry Kiefer]

8051 - there is no way around. Several manufacturers if you use the standard
version.

I don't think there is a generic German or Japanese alternative. H8 and C167
works very well, but single/almost single sourced!

regards -
Henry

 

[Vladimir Vassilevsky]

I heard from a committed PIC booster that "yes, the architecture sucks
for programming, but the PIC never has delivery problems".

Does anyone have experience with alternatives to the PIC (and 8051
derivatives) that show that this is not a problem?

Consider the 68HCxx lines from Motorola.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com

 

[Tim Wescott]

8051 - there is no way around. Several manufacturers if you use the
standard version.

I don't think there is a generic German or Japanese alternative. H8
and C167 works very well, but single/almost single sourced!

Well, that does come to mind -- but I'm trying to _avoid_ a processor
who's architecture leads to sucky C code.

But I do understand that you can't walk two feet without tripping over
an 8051.

--

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

 

[Tim Wescott]

Consider the 68HCxx lines from Motorola.

How is Freescale for delivery? I used a 68HC11 variant many moons ago
and ran into delivery problems starting with my request for samples.

--

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

 

[Spehro Pefhany]

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.

What kind of processing power do you need? The newer PICs are not as
bad as the 12/16 series, and actually are not a bad fit for HLLs.
OTOH, esp the J series low-voltage process chips 24F/24H-- you'll want
to have a close gander at the flash specs. The peripherals are where
you're going to have migration issues whether its between members of a
family, between processor families with firmware coded in a HLL, or
whatever. Exact multi-sourced alternatives tend to have rather
primitive peripherals, which could make your hardware *and* firmware
ugly. BTW, Microchip is pushing the 24 chips as being only marginally
more costly than the equivalent 18F chips, but see the above caveat.

OTOH, if it's a very simple and straightforward design with 8K or
whatever of code memory, it's probably simpler and better to just code
for whatever chip the client wants and be done with it. It's certainly
possible to write solid code for any of the alternatives, there are
just a few 'unique' gotchas with the PICs. I'm currently using PIC
12/16/18/24, 8051, MSP430 and ARM, and (rarely these days) AVR.

disclaimer: I'm a uChip registered consultant and Design House.

Best regards,
Spehro Pefhany

 

[Vladimir Vassilevsky]

How is Freescale for delivery? I used a 68HC11 variant many moons ago
and ran into delivery problems starting with my request for samples.

I can't remember anything bad except there were some inventory problems
when they where adopting ROHS.

VLV

 

[Joerg]

I'll second that.

Well, that does come to mind -- but I'm trying to _avoid_ a processor
who's architecture leads to sucky C code.

But I do understand that you can't walk two feet without tripping over
an 8051.

Exactamente, and there's a reason for that. So far I haven't brought
myself yet to using any other uC mostly because of single-source
concerns. I might do an MSP some day but first they have to come up with
more detailed HW specs. Which, after half a year of waiting for a
response, is unlikely to happen.

Spehro brought up an important point: I'd rely as little as possible on
on-chip peripherals because that can really corner your client some day.

 

[Luhan]

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

Multiple sourcing is a bit of a fiction in protecting you from
shortages.. Once the total demand for anything exceeds the total
supply, you are screwed.

Luhan

 

[Jim]

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

Hi Tim,
I followed your other PIC thread asking about C compilers. I've used PICs
for many years designing into many projects using many 10's of thousands of
parts. Yes we have had compiler/IDE problems as we have with Motorola, ST,
Fujitsu etc. and don't even mention AVR! - ( no flame intended, just my
personal experience)

I've never baulked at writing 'C' for PICs or any other microcontroller as
this is generally why we use 'C' isn't it?, portability. Writing PIC
assembler (did this for a few years - along time ago), now that was a pain.
Especially when other micros were so easy. But 'C' ?, no problem for me or
my collegues.

Just as others have said, pick an established compiler/IDE and you'll
generally be ok.

I've personally never picked a microcontroller for a project based soley on
the compiler/IDE, but I guess if costs are not an issue then why not.

If you really want to choose a different micro containing the sort of
peripherals Microchips PIC devices do(to appease your customer), then I
would recommend ST7. The IDE (free from ST) is robust, the compiler (free up
to 16k), is a breeze and the micro is really good. Pricing of parts is also
very competative.
http://mcu.st.com/mcu/modules.php?name=mcu&file=familiesdocs&FAM=15 for lots
of info, IDE, tools, examples etc.
http://www.cosmic-software.com/st7.php for free cosmic compiler/ide info and
stuff

Hope it helps
Jim

 

[Henry Kiefer]

Add a HAL (hardware abstraction layer). I've done that for converting from
8051 to C166 using the same C code for i2c bit-banging. All what I need was
to change 4 c-functions, each one a single C line. Three for the completely
different port structure on the two processors. One to have a new
time-constant for the MUCH faster C166 as a delay function. The same code,
the same C compiler (with different extension for the cpu). Work done in 5
minutes. The new systems jumped 8000x times faster!

As Joerg suggested, use the integrated peripherals in a modest sense. Most
can be done in software on a RISC.

ARM is another good one. Especially the new Cortex kernel.


- Henry

 

[Jim Granville]

How is Freescale for delivery? I used a 68HC11 variant many moons ago
and ran into delivery problems starting with my request for samples.

The HC11 I think is pretty much in run-out mode, but their HC908
family seems to be getting resources.

-jg

 

[Jim Granville]

Multiple sourcing is a bit of a fiction in protecting you from
shortages.. Once the total demand for anything exceeds the total
supply, you are screwed.

That's true, but single-source parts DO have a risk exposure not
shared by perceived multi-source parts, and that is trading speculation.

With a single sourced part, many people know the exact state of the
supply chain, and so "commodity trading" is relatively easy.

If you think that's myth, next time a part goes on allocation, or short
supply, see how many quotes with shorter lead times, have higher prices
(surprise!)

-jg

 

[Pete Fenelon]

How is Freescale for delivery? I used a 68HC11 variant many moons ago
and ran into delivery problems starting with my request for samples.

The bigger a customer you are the more likely Freescale is to have what
you want, is the simple answer based on my experience with them!

HC11 is pretty much dead now, they'll probably try to nudge you
into an HC08 or HC12. Both have nothing egregiously C-unfriendly
in them, the '08 needs a bit of pseudoregister help from the compiler
runtime but otherwise no real problems, and the '12 in particular
has evolved into a lovely little micro.

pete

 

[Paul Carpenter]

On Saturday, in article
<[email protected]>

Beware of multiple source and pseudo multiple source, I remember getting
caught on Sony/Harris triple video A/D chip, whereby Harris resold the
Sony part with their badge on. So you still had single source.

Well, that does come to mind -- but I'm trying to _avoid_ a processor
who's architecture leads to sucky C code.

C167 may be sucky architecture for C, however the H8 is not. having used
severla with GNU compiler for nearly 10 years now.

But I do understand that you can't walk two feet without tripping over
an 8051.

My worry is how second sourced you want to be with everytime you turn around
and someone else's version runs on different voltages, pinouts, crystal
spec, clocks per cycle etc..

This applies to nearly ALL components. Amazing how many parts are actually
made in one batch and by the time most engineers have got to pre-production
manufacturer decided NOT to make anymore as they were not selling enough.

 

[Jonathan Kirwan]

That's true, but single-source parts DO have a risk exposure not
shared by perceived multi-source parts, and that is trading speculation.

With a single sourced part, many people know the exact state of the
supply chain, and so "commodity trading" is relatively easy.

If you think that's myth, next time a part goes on allocation, or short
supply, see how many quotes with shorter lead times, have higher prices
(surprise!)

Interesting point to think about. Thanks.

Jon

 

[Ben Jackson]

being reminded of all the drawbacks to writing software for the PIC.

If you decide you want C for the PIC, you should buy one of the
commercial offerings. I've used SDCC (free) off and on for pic14 (12F*,
16F*) and pic16 (18F*) and you constantly have to check the assembly
for problems. I keep telling myself that I should not try to use up
my supply of PICs but instead throw them away and save myself the
irritation.

to my mind the soonest are the AVR and the MSP430xxx lines,

How single is single? Lots of AVRs have similar capabilities and
compatible footprints. They're also better than Microchip about making
the transition to upgraded parts easy.

Having a real GCC toolchain for your microcontroller is a luxury that's
hard to give up once you've tried it!

 

[Henry Kiefer]

C167 may be sucky architecture for C, however the H8 is not. having used
severla with GNU compiler for nearly 10 years now.

The C166 and it's newer version C167 is a very fast processor. Even in C it
is. The Keil C compiler optimizes very good. In the US I think they would
say "atomic performance". I saw the compiler output and there was not very
much "entropy"! My first processor was the ancient 6502 - so I'm surely an
old bit-shuffler.
The bad news is: Keil is very high-priced.

Having a problem with reading the assembler code for C166 is just a human
problem. If you want Assembler programming and don't make that every day,
then another architecture is maybe better. The shiftable register array is a
nightmare for humans.

(I worked for Phytec)


I don't know much about the H8. Read some datasheets and found it an
interesting cpu.


- Henry
(6502/6802, 6809, 68K, x86, 8085/Z80, 8051, C166/C167, 29K, C196, PSoC M8C)

 

[Thad Smith]

Well, that does come to mind -- but I'm trying to _avoid_ a processor
who's architecture leads to sucky C code.

My primary concerns are part availability, ability to do the job
(throughput, size, power issues, cost, and I/O capability), and a good
compiler. For the Microchip parts, I find Hi-Tech to be a good compiler.

But I do understand that you can't walk two feet without tripping over
an 8051.

He he, programming those in assembler can turn into an art form!

 

[Tim Wescott]

On Saturday, in article
<[email protected]>
[email protected] "Tim Wescott" wrote:

-- snip --

My worry is how second sourced you want to be with everytime you turn around
and someone else's version runs on different voltages, pinouts, crystal
spec, clocks per cycle etc..

This applies to nearly ALL components. Amazing how many parts are actually
made in one batch and by the time most engineers have got to pre-production
manufacturer decided NOT to make anymore as they were not selling enough.

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.

--

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