R
Russell Shaw
Pete said: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.