PBP & 16F690 bug?

I am working with the 16F690 in the new micro QFN 20 package. It works fine but displays a wierd bug with the PBP shiftout function. I use pin RB6 as the shift clock, RC7 as the shift data output and RB4 as data in(not used at this point). RB5 is an LED output to show that there is shiftout communication. I set it high, shiftout a few bytes, look for a button press, and when the button is released, turn the LED back off by clearing the bit.
Now, here's the problem... When the shiftout command is called, RB5 is immedietly cleared, effectively turning the LED off. I have bypassed the shiftout statements and the LED stays high. I tried another LED on RC4 and it worked fine. The code is just a couple of lines, and the RB5 pin is definitely cleared when entering shiftout. I will post it if need be, but it is extremely simple. I have even tried substituting while-when for the if-then button sheck statement.
Eventually I will go to hardware SPI, but for versatility, would like to get this working. Any ideas?

Have you disabled the Analog stuff on PORTB.4 and PORTB.5 ?

ANSELH=0

Yes sir. I cleared the ANSEL register. Wow...Quick response!

Sorry i just edited above... ANSELH=0

Quote:

---

Originally Posted by mister_e

Sorry i just edited above... ANSELH=0

---

I did ANSEL, not ANSELH. Why would the pin revert to a 0/input when invoking shiftout even if ANSELH is high?

As they are analog by default, i guess it's one of those weird thing it could do. But Why B.5 when the Clock signal apear on B.6.... because of the combination of the external load, Capacitance, TRIS switching AND internal A/D multiplexer i guess... i didn't spend too much time in the datasheet to study how it could happen but if the ANSELH is not cleared, those pin will certainely be analog, not digital as you want.

You know, sometimes it's better to don't know all the reasons and stay happy when it works ;)

It's just weird that they didn't place the ANSEL and ANSELH register in the A/D datasheet section...

Quote:

---

Originally Posted by mister_e

As they are analog by default, i guess it's one of those weird thing it could do. But Why B.5 when the Clock signal apear on B.6.... because of the combination of the external load, Capacitance, TRIS switching AND internal A/D multiplexer i guess... i didn't spend too much time in the datasheet to study how it could happen but if the ANSELH is not cleared, those pin will certainely be analog, not digital as you want.

You know, sometimes it's better to don't know all the reasons and stay happy when it works ;)

It's just weird that they didn't place the ANSEL and ANSELH register in the A/D datasheet section...

---

Thanks, I'll try the fix tonight. Wierd quirk though...Huh?

Quote:

---

Originally Posted by mister_e

As they are analog by default, i guess it's one of those weird thing it could do. But Why B.5 when the Clock signal apear on B.6.... because of the combination of the external load, Capacitance, TRIS switching AND internal A/D multiplexer i guess... i didn't spend too much time in the datasheet to study how it could happen but if the ANSELH is not cleared, those pin will certainely be analog, not digital as you want.

You know, sometimes it's better to don't know all the reasons and stay happy when it works ;)

It's just weird that they didn't place the ANSEL and ANSELH register in the A/D datasheet section...

---

I cleared the ANSELH register to 0 and all is right with the world...Thanks for the help.

Ron

Great to know it's working. It's not often i saw TWO ANSEL registers so.. kinda interesting to know it exist :)

An interesting aside to this saga. Jeff from Melabs emailed me back about this quirk. This is important for anyone using Analog inputs with digital outputs. When the uP is commanded to change a bit, it reads, modify,writes the entire port. Since Analog bits are read as zero, when the port is rewritten, any Analog bit will be written as a zero. Even if it was used as a digital high output,as was in my case. Verrrry interesting!

Ron