Maker Pro
Maker Pro

PIC16F648A - to wastebasket !!!

G

Grzegorz Zalot

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:[email protected]
 
M

Mark A. Odell

Grzegorz Zalot said:
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.
 
G

Grzegorz Zalot

Hallo Mark A. Odell !:
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

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

http://www.complex.org.pl/
mailto:[email protected]
 
T

Tauno Voipio

Grzegorz Zalot said:
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 !

How about Atmel AVR's?

Tauno Voipio
tauno voipio @ iki fi
 
M

Mark A. Odell

8051's are always good, IMHO.
How about Atmel AVR's?

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

Grzegorz Zalot

Hallo Mark A. Odell !:
............
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.

--
Grzegorz Zalot

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

http://www.complex.org.pl/
mailto:[email protected]
 
L

Leon Heller

Grzegorz Zalot said:
Hallo Mark A. Odell !:
...........

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

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

Leon
 
M

Mike Page

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

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

Jim Granville

Mark said:
8051's are always good, IMHO.


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

-jg
 
M

Mike V.

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

Mark A. Odell

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

Spehro Pefhany

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
 
A

Active8

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
 
S

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.

Search google groups for the part number + EEPROM + corruption


Best regards,
Spehro Pefhany
 
S

Steven

Grzegorz said:
Hallo Mark A. Odell !:
...........

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

And you just said they are crap!
 
G

Grzegorz Zalot

Hallo Steven !:
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.

--
Grzegorz Zalot

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

http://www.complex.org.pl/
mailto:[email protected]
 
P

Patrick Gomolchuk

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
 
S

Spehro Pefhany

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

Best regards,
Spehro Pefhany
 
P

Pete Fenelon

In comp.arch.embedded Spehro Pefhany said:
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...

pete
 
J

Jim Granville

Spehro said:
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..

:)

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

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

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
 
Top