> re: Code Protect Bit
>
>    Byron (and others in this discussion), why is this an issue? Setting the
> code protect bit is kind of like pulling a pin on a hand grenade and letting
> go of the handle. Once you've done it, you're committed... I can't see any
> R&D-related purpose in setting the bit. Asking Microchip to allow erasure of
> the bit, or an alternative bit, in the "JW" parts, seems a bit ridiculous to
> me considering the chip process issues. Byron, this is not directed to you
> but the discussion in general.

I DISAGREE!  Writing a program .HEX file, with the code-protect fuse set,
and testing it in a windowed JW part just before handing it over the wall to
manufacturing makes PERFECT sense to me.  This may sound overly
anal-retentive to you, but I for one am most comfortable if the file being
programmed by our trusty laborers is EXACTLY what I give them, not one that
they, or I, or anybody else gave ``just one last tweek'' either by editing
the .HEX file (by hand?  with a filter utility?), or by one last compile (on
the same platform?  with exactly the same version of assembler, include
files, etc.?).  Nor will I hand them a non-code-protected file and expect
them to (``please, now, don't forget!'') manually set the code-protect on
each part they manufacture.  So, until the 17C42 was replaced by the 17C42A,
I trusted a -JW part to test my code, including FINAL test of the EXACT .HEX
file given to manufacturing.

The alternative is to use -JW parts for routine development, without code
protect, and reserve ``FINAL'' testing for an OTP part, with code-protect
set.  That probably means you'll go through a few OTP parts in the
engineering department; whereas before OTP devices could be viewed as
stricly production components, now some are development consumeables.

One small bonus: you all know, don't you, that OTP parts may not start out
with all-zero RAM, whereas -JW parts may be more likely to?  If it's not in
the PIC FAQ, it should be: things that work in windowed parts sometimes fail
in OTP parts, if you were relying on some other power beyond your own code
to initialize your RAM variables for you.

Anyway, I was peeved at Microchip for making this change without LOUD
WARNING!  I begged and wheedled my local rep for pre-release samples of the
17C44, and he begged and wheedled Microchip on my behalf and got a couple of
them for me, and within 2 hours, I suddenly had one rare and hard-to-come-by
paperweight, plus one unobtainalbe and seldom-seen doorstop.  I think
Microchip should put a prominent NEON ORANGE STICKER on every new-technology
windowed part, reading:

    WARNING!  DO NOT SET CODE-PROTECT FUSE IN THIS DEVICE!  RTFM!

Otherwise, I think they come off looking like they're playing a cynical game
of ``Gotcha!  Here, can we sell you another one now?''

All opinions personal.

Peter F. Klammer, Racom Systems Inc.                   PKlammer@ACM.Org
6080 Greenwood Plaza Boulevard                            (303)773-7411
Englewood, CO  80111                                  FAX:(303)771-4708