Single-Source PIC, AVR & Alternatives

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

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

--
www.ehydra.dyndns.info



"Tim Wescott" <tim@seemywebsite.com> schrieb im Newsbeitrag
news:orKdneX-ZYa_QefYnZ2dnUVZ_tyinZ2d@web-ster.com...
> 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

Tim Wescott wrote:

> 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

Henry Kiefer wrote:

> 
> 
> "Tim Wescott" <tim@seemywebsite.com> schrieb im Newsbeitrag
> news:orKdneX-ZYa_QefYnZ2dnUVZ_tyinZ2d@web-ster.com...
> 
>>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.
>>
 > 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

Vladimir Vassilevsky wrote:

> 
> 
> Tim Wescott wrote:
> 
>> 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.
> 
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

On Sat, 09 Dec 2006 07:54:19 -0800, the renowned Tim Wescott
<tim@seemywebsite.com> wrote:

>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
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Tim Wescott wrote:

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

Tim Wescott wrote:

> Henry Kiefer wrote:
> 
>>
>>
>> "Tim Wescott" <tim@seemywebsite.com> schrieb im Newsbeitrag
>> news:orKdneX-ZYa_QefYnZ2dnUVZ_tyinZ2d@web-ster.com...
>>
>>> 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.
>>>
>  > 8051 - there is no way around. Several manufacturers if you use the
>  > standard version.
>  >

I'll second that.


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

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.

-- 
Regards, Joerg

http://www.analogconsultants.com

Tim Wescott wrote:
> 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

"Tim Wescott" Wrote:
>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