>
> Lorick wrote:
> >I think that worked, but I'm not sure.  For now I'm considering that this
> >LVP bit was the problem but I might have somehow done something else that
> >worked which I'm not aware of...but I doubt that.
> ><snip>
> >So does anyone know why this LVP bit is such an issue in my case?  How can
> >it affect something like how many times Im' allowed to loop without
> >crashing, or if I can or can't have a goto infinite loop?
>
> The one concrete effect that the LVP bit has is that if LVP is enabled,
> then
> RB3 is NOT available as a digital input/output.

That is correct.

> I don't know if you were
> using this pin (sorry - I didn't keep the thread), but if you are, then you
> will surely have mysterious results.

That too is correct.

> Unfortunately, uChip defaults LVP to
> enabled, which means that code that worked on a C7xx cousin won't
> necessarily work if dropped into the F87xx equivalent.

I disagree. Explanation below.

>My sense is that
> usually uChip does a pretty good job of making defaults such that things
> tend to be backward compatible - not the case here.  imho, LVP should
> default to disabled.

uChip made a mistake, but this isn't it. LVP has to be enabled by default
because if it wasn't, then one would be required to have a HV programmer
to program the part, thereby defeating the entire purpose of making LVP
available. The fact of the matter is that the part isn't usable until it
has been programmed for the first time, and the first time it is programmed
one can simply turn LVP off, gaining RB3 back but losing the ability to LVP
in that way. Of course since the 16F87X parts can reprogram their program
memory, it's a no brainer to simply drop a small bootloader on the chip the
first time it's programmed, turn off LVP, and then use the bootloader to
reprogram the chip from then on. Take a look at Tony Nixon's ROMZap at
www.picnpoke.com as a superb example.

LVP definitely must be on by default.

Now the mistake that uChip made IMHO is sticking LVP right in the middle
of a perfectly usable 8 bit port. Here they could have take several more
useful paths:

1) Move the pin to the end of a port. Then at least you can get seven
consecutive bits.

2) use port A or port E neither of which are full ports anyway.

3) A bit more difficult: on the 44 pin PLCC parts move LVP to its own pin.
I have no clue how to do this with a single die, but it would have been nice
to have a separate LVP from RB3.

The pin placement was poor. But the default is absolutely correct because
now one can build a programmer from just a cable.

BAJ