Single-Source PIC, AVR & Alternatives

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

--

"Tim Wescott" schrieb im Newsbeitrag news:orKdneX-ZYa_QefYnZ2dnUVZ snipped-for-privacy@web-ster.com...

Consider the 68HCxx lines from Motorola.

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

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

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

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

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

VLV

I'll second that.

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

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

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.

for lots of info, IDE, tools, examples etc. for free cosmic compiler/ide info and stuff

Hope it helps Jim

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

--

"Joerg" schrieb im Newsbeitrag news:lACeh.27957$ snipped-for-privacy@newssvr14.news.prodigy.net...

am

pain

I'm

story

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

-jg

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

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"

...

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.

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

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
    PC Services
              GNU H8 & mailing list info
             For those web sites you hate

Interesting point to think about. Thanks.

Jon

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.

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

http://www.ben.com/

"Paul Carpenter" schrieb im Newsbeitrag news: snipped-for-privacy@pcserviceselectronics.co.uk...

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)

--

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.

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

--
Thad

-- snip --

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

--

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