See intra-code comments below....

> I know that I'm going to learn something here that I will never make the
> same mistake on again, but I am having a major problem with code that I
have
> developed.  I am writing a hexidecimal value to PORTB and the value is not
> always the same as what I wrote to it.  I set breakpoints immediately
after
> I set the value and I still see the difference so I know that something
else
> that I have done is not modifying it.  Originally I was using a lookup
table
> to get my values but to simplify and try to debug this problem I am just
> writing the output to the port manually.  The values are always close to
> what I have written but they are not always correct.  It also seems that
> bits 2 or 3 are the bits affected.  Here is the code that I'm using
(excuse
> all the commented out because I am trying to simplify to isolate the
> problem).

...

>
> Case 9:
>  PORTB = 0xFF;
>  angle=0;
> break;
> }
>
> output_low(PIN_B0);
> delay_us(10);
> output_high(PIN_B0);
>

Aha!  output_low induces a Read-Modify-Write operation, probably a "BCF
06,0".  The contents of PortB (the *real* PortB, not your variable) are
read, bit 0 is reset, and the contents are written out to the port.  Now, if
your outputs haven't stabalized before this operation reads the status of
the outputs, you will get invalid results asserted on your port.

Quoting from the 16F87X manual:
"All write operations are read-modify-write operations.
Therefore, a write to a port implies that the port pins are
read, the value is modified and then written to the port
data latch."(c)

How about putting an obscenely long delay *after* the end of the switch
statement closing brace and *before* your output_low() instructions to see
if this helps.  Thusly:

...
> Case 9:
>  PORTB = 0xFF;
>  angle=0;
> break;
> }
>

// Give the output pins some time to stabilize before another RMW
instruction corrupts
// information on our port.
DELAY_US(100);


> output_low(PIN_B0);
> delay_us(10);
> output_high(PIN_B0);
>
...

Note that this isn't such a problem with your PORTB=lvalue statements.
Those compile to something like this:

03882 ....................  PORTB=0XFF;
03883 MOVLW  FF
03884 BCF    03,5
03885 MOVWF  06

This doesn't involve RMW instructions.

My 0x02 cents.
-d

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's