PIC16F648A - to wastebasket !!!

Grzegorz Zalot wrote in news: snipped-for-privacy@alpha.pl:

I feel your pain. Sounds like it's time to visit TI for the MSP430.

Hallo Mark A. Odell !:

We make one design with msp430f435 (C IDE430 from Romania) and we are very satisfied !

I think on Motorola ..... or the new 51' from Philips !

news: snipped-for-privacy@alpha.pl:

How about Atmel AVR's?

Tauno Voipio tauno voipio @ iki fi

"Tauno Voipio" wrote in news:ly06b.367$ snipped-for-privacy@read3.inet.fi:

Yes, Grzegorz you should definitely check out the AVR's. Clean architecure.

Hallo Mark A. Odell !: ...........

But we have bad "adventures" with AVRs in noisy environment (AT90S1200 - very poor !!!). PICs are very good.

very

I always connect the AVR RESET pin to an RC - 10k to Vcc and 100n to ground. It helps a lot.

Leon

The MSP430F149 is really great, but not without problems. I haven't checked documentation recently, but I experienced major problems with the ADC by clearing ADC12IFG manually. It won't stay clear, even with the ADC powered down. If you read ADC12MEMXX instead, it behaves. Now that is a workable workaround.

Regards, Mike.

-- Mike Page BEng(Hons) MIEE

Until you run out of registers, or need priority interrupts.... AVRs are also single sourced, and going by the latest 'rationalizes', have a relatively short 'half life'...

-jg

So do you get erroneous readings 100% of the time? Or some of the time?

Jim Granville wrote in news: snipped-for-privacy@designtools.co.nz:

So no worse than PICs then. Except that you have a cleaner, C-friendly chip. --

- Mark ->

--

Except for the last bit. Microchip have been pretty good about keeping their older designs and even older revisions available. Motorola, for example, would just discontinue the first version when the "A" version became available. Maybe they are waiting until they get all the bugs out of the newer chips. ;-)

Best regards, Spehro Pefhany

any horror stories about the Atmel AT90[L]S4434 or the AT90x[L]S8535 AVRs? i haven't been able to dig into them yet.

brs, mike

Search google groups for the part number + EEPROM + corruption

Best regards, Spehro Pefhany

And you just said they are crap!

Yes, the new "surprise" 16F648 .... I thing, Microchip must better test the chips, and defective chips has to exchange !

The PICs are not bad generally - but the "surprise" with 16F648 is tragical.

Hello Grzegorz,

I'm sorry to hear that 1) It turned out to be silicon issue 2) The workaround is unsuitable for your requirements.

Their 'workaround' also explains why my app works without fault.

Best Regards, Patrick Gomolchuk

Some of the new 18F chips have serious issues with operation above

Sanghi needs to shake things up there..

Best regards, Spehro Pefhany

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

pete

:)

Chip vendors always over-estimate clock speeds, and under-estimate the inertia and importance of software.

eg I have a 1996 AVR databoook, that claims 24MHz. Then, they actually made some devices, and released 8MHz, which has recently moved to 16MHz with a shrink.

Should meet marketings 1996 value around 2008... ? :)

Pete Fenel> IMHO, dsPIC (despite the fact that it's a decent enough architecture,

An ARM to emulate a PIC - now there's a scary thought !

That aside, you may have a point :

Philips new ARM devices are small enough to be firmly in the microcontroller space, and the newest Cygnal device hits 100MHz, with a HW 16x16 MAC. Both use mature cores, with wide SW support, and will overlap with dsPIC. Philips also have a raft of 8/14/20 pin tiny uC appearing, that will challenge the bottom feeder PICs

-jg