PIC16F648A - to wastebasket !!!

G

Grzegorz Zalot

Guest
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.
Click to expand...
Source :

http://www.microchip.com/download/lit/suppdoc/errata/80151e.pdf

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
 
Grzegorz Zalot <complex@alpha.pl> wrote in news:3F5889C0.3020402@alpha.pl:

Any my "workaround" : wastebasket !!!!

or simply "sleep" Microchip ! This is silly and offensive !
Click to expand...
I feel your pain. Sounds like it's time to visit TI for the MSP430.

--
- Mark ->
--
 
Hallo Mark A. Odell !:
Grzegorz Zalot <complex@alpha.pl> wrote in news:3F5889C0.3020402@alpha.pl:


Any my "workaround" : wastebasket !!!!

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


I feel your pain. Sounds like it's time to visit TI for the MSP430.
Click to expand...
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
 
"Grzegorz Zalot" <complex@alpha.pl> wrote in message
news:3F589346.3090201@alpha.pl...
Hallo Mark A. Odell !:
Grzegorz Zalot <complex@alpha.pl> wrote in
news:3F5889C0.3020402@alpha.pl:


Any my "workaround" : wastebasket !!!!

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


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


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
Click to expand...
How about Atmel AVR's?

Tauno Voipio
tauno voipio @ iki fi
 
"Tauno Voipio" <tauno.voipio@iki.fi.SPAMBAIT_REMOVE.invalid> wrote in
news:ly06b.367$AB3.254@read3.inet.fi:

I think on Motorola ..... or the new 51' from Philips !
Click to expand...
8051's are always good, IMHO.

How about Atmel AVR's?
Click to expand...
Yes, Grzegorz you should definitely check out the AVR's. Clean
architecure.

--
- Mark ->
--
 
Hallo Mark A. Odell !:
............
How about Atmel AVR's?


Yes, Grzegorz you should definitely check out the AVR's. Clean
architecure.
Click to expand...
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
 
"Grzegorz Zalot" <complex@alpha.pl> wrote in message
news:3F58A39F.9070509@alpha.pl...
Hallo Mark A. Odell !:
...........

How about Atmel AVR's?


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


But we have bad "adventures" with AVRs in noisy environment (AT90S1200 -
very
poor !!!). PICs are very good.
Click to expand...
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
 
Mark A. Odell wrote:
Grzegorz Zalot <complex@alpha.pl> wrote in news:3F5889C0.3020402@alpha.pl:


Any my "workaround" : wastebasket !!!!

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


I feel your pain. Sounds like it's time to visit TI for the MSP430.
Click to expand...
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 www.eclectic-web.co.uk
 
Mark A. Odell wrote:
"Tauno Voipio" <tauno.voipio@iki.fi.SPAMBAIT_REMOVE.invalid> wrote in
news:ly06b.367$AB3.254@read3.inet.fi:

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

8051's are always good, IMHO.

How about Atmel AVR's?

Yes, Grzegorz you should definitely check out the AVR's.
Clean architecture.
Click to expand...
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?


Grzegorz Zalot <complex@alpha.pl> wrote in message news:<3F5889C0.3020402@alpha.pl>...
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 :

http://www.microchip.com/download/lit/suppdoc/errata/80151e.pdf

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
Click to expand...
 
Jim Granville <jim.granville@designtools.co.nz> wrote in
news:3F595F82.14D6@designtools.co.nz:

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

8051's are always good, IMHO.

How about Atmel AVR's?

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

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'...
Click to expand...
So no worse than PICs then. Except that you have a cleaner, C-friendly
chip. --
- Mark ->
--
 
On 8 Sep 2003 13:02:38 GMT, the renowned "Mark A. Odell"
<nospam@embeddedfw.com> wrote:

Jim Granville <jim.granville@designtools.co.nz> wrote in
news:3F595F82.14D6@designtools.co.nz:

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

8051's are always good, IMHO.

How about Atmel AVR's?

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

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

So no worse than PICs then. Except that you have a cleaner, C-friendly
chip. --
Click to expand...
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
 
In article <ju0plvcvscnoc2p81v01f1nev82rl5piuv@4ax.com>,
speff@interlog.com says...
On 8 Sep 2003 13:02:38 GMT, the renowned "Mark A. Odell"
nospam@embeddedfw.com> wrote:

Jim Granville <jim.granville@designtools.co.nz> wrote in
news:3F595F82.14D6@designtools.co.nz:

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

8051's are always good, IMHO.

How about Atmel AVR's?

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

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'...
Click to expand...
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

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

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
Click to expand...
 
On Mon, 08 Sep 2003 19:22:45 GMT, the renowned Active8
<mcolasono@earthlink.net.invalid> wrote:

In article <ju0plvcvscnoc2p81v01f1nev82rl5piuv@4ax.com>,
speff@interlog.com says...
On 8 Sep 2003 13:02:38 GMT, the renowned "Mark A. Odell"
nospam@embeddedfw.com> wrote:

Jim Granville <jim.granville@designtools.co.nz> wrote in
news:3F595F82.14D6@designtools.co.nz:

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

8051's are always good, IMHO.

How about Atmel AVR's?

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

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


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.
Click to expand...
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
 
Grzegorz Zalot wrote:
Hallo Mark A. Odell !:
...........

How about Atmel AVR's?


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


But we have bad "adventures" with AVRs in noisy environment
(AT90S1200 - very poor !!!). PICs are very good.
Click to expand...
And you just said they are crap!
 
Hallo Steven !:
Grzegorz Zalot wrote:

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

How about Atmel AVR's?


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


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


And you just said they are crap!
Click to expand...
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
 
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





"Grzegorz Zalot" <complex@alpha.pl> wrote in message
news:3F5889C0.3020402@alpha.pl...
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 :

http://www.microchip.com/download/lit/suppdoc/errata/80151e.pdf

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
Click to expand...
 
On Tue, 09 Sep 2003 16:04:13 +0200, the renowned Grzegorz Zalot
<complex@alpha.pl> wrote:


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.
Click to expand...
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
 
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..
Click to expand...
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
 
Spehro Pefhany wrote:
On Tue, 09 Sep 2003 16:04:13 +0200, the renowned Grzegorz Zalot
complex@alpha.pl> wrote:

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.

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..
Click to expand...
:)

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... ? :)

<paste>
Pete Fenelon wrote:
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...
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top