Single-Source PIC, AVR & Alternatives

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

--
www.ehydra.dyndns.info


"Joerg" <notthisjoergsch@removethispacbell.net> schrieb im Newsbeitrag
news:lACeh.27957$wP1.16605@newssvr14.news.prodigy.net...
> 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:

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

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

-jg

Luhan wrote:

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

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

Tim Wescott <tim@seemywebsite.com> wrote:
>> 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.

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
-- 
pete@fenelon.com "he just stuck to buying beer and pointing at other stuff"

On Saturday, in article
     <uY6dnVbOtoHWc-fYnZ2dnUVZ_rjinZ2d@web-ster.com>
     tim@seemywebsite.com "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.
>>>
...
>>>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.

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.

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

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.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

On Sun, 10 Dec 2006 10:15:57 +1300, Jim Granville
<no.spam@designtools.maps.co.nz> wrote:

>Luhan wrote:
>
>> 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.
>
>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

On 2006-12-09, Tim Wescott <tim@seemywebsite.com> wrote:
> 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!

-- 
Ben Jackson AD7GD
<ben@ben.com>
http://www.ben.com/

"Paul Carpenter" <paul$@pcserviceselectronics.co.uk> schrieb im Newsbeitrag
news:20061209.2216.323102snz@pcserviceselectronics.co.uk...
> > >
> >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.

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)

--
www.ehydra.dyndns.info

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

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!

-- 
Thad

Paul Carpenter wrote:
> On Saturday, in article
>      <uY6dnVbOtoHWc-fYnZ2dnUVZ_rjinZ2d@web-ster.com>
>      tim@seemywebsite.com "Tim Wescott" wrote:

-- snip --

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