1. Home
  2. Embedded Programming
  3. PIC16F648A - to wastebasket !!!

PIC16F648A - to wastebasket !!!

How Microchip reacted onto problems with PIC16F648A :

3. Module: Data EEPROM Memory > 1. PIC16F648A Silicon revision A1. > Unexpected program execution may occur during > data EEPROM write cycles. > Work around > Execute a SLEEP instruction immediately after > setting the EECON1 WR bit and allow the EEIF to > wake the processor from Sleep. This requires the > PEIE bit of the INTCON register and the EEIE bit > of the PIE1 register to be set. All other interrupt > enables must be cleared so that only the EE write > completion will wake the processor.

Source :

formatting link

Any my "workaround" : wastebasket !!!!

or simply "sleep" Microchip ! This is silly and offensive !

--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl
Reply to
Grzegorz Zalot
Loading thread data ...

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.

--
- Mark ->
--
Reply to
Mark A. Odell

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 !

--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl
Reply to
Grzegorz Zalot

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

How about Atmel AVR's?

Tauno Voipio tauno voipio @ iki fi

Reply to
Tauno Voipio

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

8051's are always good, IMHO.

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

--
- Mark ->
--
Reply to
Mark A. Odell

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

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

--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl
Reply to
Grzegorz Zalot

very

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

Leon

--
Leon Heller, G1HSM
leon_heller@hotmail.com
http://www.geocities.com/leon_heller
Reply to
Leon Heller

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

formatting link

Reply to
Mike Page

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

Reply to
Jim Granville

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

Reply to
Mike V.

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

--

Reply to
Mark A. Odell

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

--
"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
Reply to
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

Reply to
Active8

Search google groups for the part number + EEPROM + corruption

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
Reply to
Spehro Pefhany

And you just said they are crap!

Reply to
Steven

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.

--
Grzegorz Zalot

complex ltd.
office tel/fax : +48 32 2505840
mobil : +48 501 301515

http://www.complex.org.pl/
mailto:complex@alpha.pl
Reply to
Grzegorz Zalot

Hello Grzegorz,

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

999 times out of 1000 it turns out to be firmware (thank goodness).

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

Best Regards, Patrick Gomolchuk

Reply to
Patrick Gomolchuk

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

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
Reply to
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

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

:)

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

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.