PIC16F648A - to wastebasket !!!

[Russell Shaw]

Pete Fenelon wrote:

In comp.arch.embedded Spehro Pefhany <speff@interlog.com> wrote:

Some of the new 18F chips have serious issues with operation above
25MHz (IIRC ??), or even, reportedly, 4MHz, despite being called
"40MHz" chips. There are ugly workarounds to allow 40MHz operation on
only some of them.

Sanghi needs to shake things up there..



The impression I get is that Microchip are gambling the whole company on
dsPIC - and that's late and not winning hearts and minds. There's a nice
legacy business in PIC16 and before, but a generation of new embedded
engineers have grown up with AVRs and suchlike and don't automatically
think of Microchip when starting a low-end design.

Trouble is, dsPIC takes them into a market segment that's already pretty
well mapped out - there's plenty of good micros and low-end DSPs in that
market space and Microchip doesn't have mind-share in those sectors.

PIC17 failed dismally. PIC18 is limping badly (not helped by the fact
that it was meant to be C-friendly and the compilers were diabolical for
quite a lot of the family's early life). dsPIC is not taking off. Unless
they have a big success in the near future it looks like "interesting
times" for Microchip.

Basically, I think they only have three things going for them:

(1) keeloq
(2) packaging, peripherals etc.
(3) the legacy market.

IMHO, dsPIC (despite the fact that it's a decent enough architecture,
and combines many good features of PIC-like Harvard RISC, conventional
micros and low-end DSP) shouldn't have happened. Microchip should've
licensed ARM for higher-end applications, put their own peripherals
onto an ARM core and provided a software emulator or a binary
translator for PIC16 apps...

If they had any sense, they'd make a dsp that matches well to
C compilers, and add support for it to gcc. Instant cult following.
That's how atmel got where they are with AVRs, but only by accident
because a hobbyist added support to gcc, as well as a few other
cheap compiler vendors. If that were to stop, i'm sure gcc/msp430
would take its place.

 

[Pete Fenelon]

In comp.arch.embedded Russell Shaw <rjshaw@iprimus.com.au> wrote:

If they had any sense, they'd make a dsp that matches well to
C compilers, and add support for it to gcc.

That is dsPIC/PIC30 - but it's running several years late.

pete
--
pete@fenelon.com "there's no room for enigmas in built-up areas" HMHB

 

[John]

Russell Shaw <rjshaw@iprimus.com.au> wrote in message news:<3F5F3B1F.3050403@iprimus.com.au>...

Pete Fenelon wrote:
In comp.arch.embedded Spehro Pefhany <speff@interlog.com> wrote:

Some of the new 18F chips have serious issues with operation above
25MHz (IIRC ??), or even, reportedly, 4MHz, despite being called
"40MHz" chips. There are ugly workarounds to allow 40MHz operation on
only some of them.

Sanghi needs to shake things up there..



The impression I get is that Microchip are gambling the whole company on
dsPIC - and that's late and not winning hearts and minds. There's a nice
legacy business in PIC16 and before, but a generation of new embedded
engineers have grown up with AVRs and suchlike and don't automatically
think of Microchip when starting a low-end design.

Trouble is, dsPIC takes them into a market segment that's already pretty
well mapped out - there's plenty of good micros and low-end DSPs in that
market space and Microchip doesn't have mind-share in those sectors.

PIC17 failed dismally. PIC18 is limping badly (not helped by the fact
that it was meant to be C-friendly and the compilers were diabolical for
quite a lot of the family's early life). dsPIC is not taking off. Unless
they have a big success in the near future it looks like "interesting
times" for Microchip.

Basically, I think they only have three things going for them:

(1) keeloq
(2) packaging, peripherals etc.
(3) the legacy market.

IMHO, dsPIC (despite the fact that it's a decent enough architecture,
and combines many good features of PIC-like Harvard RISC, conventional
micros and low-end DSP) shouldn't have happened. Microchip should've
licensed ARM for higher-end applications, put their own peripherals
onto an ARM core and provided a software emulator or a binary
translator for PIC16 apps...

If they had any sense, they'd make a dsp that matches well to
C compilers, and add support for it to gcc. Instant cult following.
That's how atmel got where they are with AVRs, but only by accident
because a hobbyist added support to gcc, as well as a few other
cheap compiler vendors. If that were to stop, i'm sure gcc/msp430
would take its place.

I am glancing over Digikey's catalog, looking at several vendors of
MPU chips. I am aware of Microchip, Amtel, TI, Cypress, and others.
It's a little confusing, even for a hobbiest. Since I have no history,
I'd like to pick a vendor with a solid future and inexpensive
development.

Gcc/Amtel is inexpensive (of course), but how smooth and solid is the
developer environment, e.g. how easy is it to debug in circuit?

How good is the MSP430? I see indicators of strong interest, but I
don't know the current or future trends.

If Microchip is heading for "interesting times", then perhaps I should
looke elsewhere. OTOH MPUs are Microchip, but TI could drop the 430
and not even sneeze.

O P I N I O N S P L E A S E

Please share your thoughts and opinions about this. Many of you have a
good sense of the future and know what really matters most in project
development and learning.

Thanks in advance.

 

[Paul Burke]

John wrote:

How good is the MSP430? I see indicators of strong interest, but I
don't know the current or future trends.

The major drawbacks of the MSP430 series (I've used it in about a dozen
projects) are:

- No 5V versions and IO not 5V tolerant.

- No versions with external bus- although there are versions with plenty
of RAM and flash, it would be nice to hook it up to some fast peripherals.

- The FLL clock oscillator requires a PhD and a brain the size of a
small planet just to read the documentation.

- The built in reset isn't very reliable. Always use a separate reset
IC- I use MCP100.

And that's it. Everything else about it is wonderful. The GCC port is
pretty reliable, the serial download works beautifully (haven't had much
luck with JTAG, largely because the GNU driver is flaky under Windouch),
lots of powerful peripherals, lots of programming examples in both C and
assembler, active support groups.

Paul Burke

 

[David Brown]

"Paul Burke" <paul@scazon.com> wrote in message
news:bjrrlf$mmofg$1@ID-128611.news.uni-berlin.de...

John wrote:



How good is the MSP430? I see indicators of strong interest, but I
don't know the current or future trends.


The major drawbacks of the MSP430 series (I've used it in about a dozen
projects) are:

- No 5V versions and IO not 5V tolerant.

That's definitely a drawback.

- No versions with external bus- although there are versions with plenty
of RAM and flash, it would be nice to hook it up to some fast peripherals.

The msp430 has a single address space of 64k - there is not much left over
on the chips with large flash and ram. The single address space is *very*
nice, and part of what makes the chip far more "C friendly" than the AVR.
If you can get away with a bit lower speed, you can make a databus out of
normal port pins - of which the msp430 has plenty.

- The FLL clock oscillator requires a PhD and a brain the size of a
small planet just to read the documentation.

Indeed - a few simple examples would make things a lot easier! But once
you've got it figured out, you can do nice things like use the internal (low
power, low cost, low accuracy) oscillator to provide the main high-speed
clock, and use a 32kHz crystal (low power, low cost, high accuracy - but low
speed) to continually calibrate the internal oscillator.

- The built in reset isn't very reliable. Always use a separate reset
IC- I use MCP100.

And that's it. Everything else about it is wonderful. The GCC port is
pretty reliable, the serial download works beautifully (haven't had much
luck with JTAG, largely because the GNU driver is flaky under Windouch),
lots of powerful peripherals, lots of programming examples in both C and
assembler, active support groups.

Paul Burke

 

[Paul Burke]

David Brown wrote:

The msp430 has a single address space of 64k - there is not much left over
on the chips with large flash and ram.

Most of them have quite big holes. Only the ones with 20-odd K of RAM
fill up the address space at all. And most fast peripherals only want a
few K (mine wanted 4k).

The single address space is *very*
nice, and part of what makes the chip far more "C friendly" than the AVR.

Yes, I was brought up with a single 64k space, 6800s through to 6809s.
Wouldn't want to change that. (except to make it a 1M linear address
space, but that's next year)

If you can get away with a bit lower speed,you can make a databus out
of normal port pins - of which the msp430 has plenty.

That's the drawback. Just can't stand the low speed, ended up using the
horrid 89C51RD2 and pouring power over it. I just want some of these
spare pins optionally made into a bus.

Paul Burke