My experiences toggling PIN_B1 on a 16F84

[Dave Y.]

I "discovered" something interesting I wanted to pass
along. I was requested by my office to build a "quick" controller for a small task controlling some new equipment we received. Sooo...I thought I would throw together a little 16F84 to do the job.

It took me 25 minutes to write the code and load it into the 16F84, that's when it all started...

The task was, in response to a signal going high on input A0, toggle the pins B1,B2,B3 and B4 at a .5 Sec rate in a particular sequence.

To toggle the various pins independently I used the line:
output_bit(PIN_Bx,!input(PIN_Bx));

The output worked great on pins B3 and B4 but would not work on pins B1 and B2.... After looking at code then the 'F84 spec sheet for the next 30 minutes trying to figure out what I missed, I found nothing.

I thought my 16F84 was bad and tried another, same problem. Then, as a test, I changed B1 and B2 to A1 and A2, and it worked. I really wanted to keep all the pins I was using together so I started investigating what it would take to make B1 and B2 work.

After some experimenting, here are two ways I discovered would "fix" the problem with pins B1 and B2:

1. Break up and slow down the statement by using:
if (input(PIN_B1)
{
delay_us(20);
output_low(PIN_B1);
}
else
{
delay_us(20);
output_high(PIN_B1);
}

Apparently the INPUT > OUTPUT sequence is just too fast and slowing it down with delay_us(20)works.

2. After some additional tinkering I found that if I added the line #use FAST_IO(B), everything worked.

I know this sounds strange but, in STANDARD_IO all I got out of the port was a very short (<1 ms) "glitch" going high. When I changed to FAST_IO it was perfect. Normally I use the 16F876/877 and I have never seen this with them.

I am not sure if I would call this a problem with CCS code or not since it works fine on all other pins except B1 and B2.

Since it took me 20 minutes to write the code and two hours to figure out why perfectly good code would not work, I thought I would pass this along to save everyone some headaches.

Dave
___________________________
This message was ported from CCS's old forum
Original Post ID: 1195

[Steve H.]

:=I am not sure if I would call this a problem with CCS code or not since it works fine on all other pins except B1 and B2.
:=
:= Dave


Hi Dave: If you look at the CCS manual and it's description of how Satandar IO works you will see that when you say,

output_bit(PIN_Bx,!input(PIN_Bx));

First it sets the port B pin to an input because you said you wanted to read the input on pin_bx: "input(PIN_Bx)"

So at this point the pin is an input. And if it is not activly being pulled up or down it may read anything because it is floating.

Then the output_pin() sets the pin_bx back to an output and forces it the way that the !input said it to.

Looking at the LST file will allow you to discover how the program is really working, not just how 'we' think it ought to be working. For instance here you would have seen the TRIS registers being toggled back and forth.

I've done many hours myself debugging 10 minutes worth of code...

;-)

Steve H.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1198

[Tomi]

<font face="Courier New" size=-1>It is easy to understand your effect.
In CCS C, if you use STANDARD_IO, the following is executed:
output_bit(PIN_Bx,!input(PIN_Bx))
means "set the port pin PIN_Bx to INPUT(!), read the value, set the PIN_Bx to the logic level (pin is still in INPUT mode!) and set the pin to output mode":
.................... output_bit(PIN_B0,!input(PIN_B0));
0061: BSF 03,5 // goto Page1
0062: BSF 06,0 // set to input
0063: BCF 03,5 // back to Page0
0064: BTFSS 06,0 // test the bit
0065: GOTO 068
0066: BCF 06,0
0067: GOTO 069
0068: BSF 06,0
0069: BSF 03,5
006A: BCF 06,0

The "output_X(PIN_Bx)" means: "set the port pin to OUTPUT mode and set the pin to the logic level" (pay attention on the reverse order).
In the FAST_IO mode, "output_bit(PIN_Bx,!input(PIN_Bx))" means:
"leave the pin in OUTPUT mode(!), read the logic level, set the new level":
.................... output_bit(PIN_B1,!input(PIN_B1));
0066: BTFSS 06,1 // no access to TRIS register!
0067: GOTO 06A
0068: BCF 06,1
0069: GOTO 06B
006A: BSF 06,1

This is correct for PICs because the port_read instruction is always reads the direct pin level (e.g. 16F877 Data Sheet Page#29 Chapter 3.1: "Reading the (PORTA...) register reads the status of the pins whereas writing to it will write to the port latch. All write operations are read-modify-write operations. Therefore a write to a port implies that the port pins are read, this value is modified, and then written to the port data latch.").
About the possible differences between portA and portB: maybe you have (or not) some external circuits attached to the port pins (e.g. LEDs, gates, inverters, etc.). When you use the "!input(...)" form in STANDRAD_IO mode the port pins could be in unpredictable voltage level (e.g. they are floating) after the input(...) ("set to input and read it") is executed.</font>
___________________________
This message was ported from CCS's old forum
Original Post ID: 1199

[Dave Y.]

Your points are well taken...and make a great deal of sense. The fact that STD IO sets to an output then and input WOULD confuse things. The curious part is why only the B1 and B2 pins?
when B3, B4 etc work fine. I dont see any difference in B2 and B3 port design that might account for this. If it was just B4-7 I could see a difference with those.

However, I will make sure I dont get caught by this one again! So simple when you take a closer look.....

Thank You!
Dave

:=I "discovered" something interesting I wanted to pass
:=along. I was requested by my office to build a "quick" controller for a small task controlling some new equipment we received. Sooo...I thought I would throw together a little 16F84 to do the job.
:=
:=It took me 25 minutes to write the code and load it into the 16F84, that's when it all started...
:=
:=The task was, in response to a signal going high on input A0, toggle the pins B1,B2,B3 and B4 at a .5 Sec rate in a particular sequence.
:=
:=To toggle the various pins independently I used the line:
:= output_bit(PIN_Bx,!input(PIN_Bx));
:=
:=The output worked great on pins B3 and B4 but would not work on pins B1 and B2.... After looking at code then the 'F84 spec sheet for the next 30 minutes trying to figure out what I missed, I found nothing.
:=
:=I thought my 16F84 was bad and tried another, same problem. Then, as a test, I changed B1 and B2 to A1 and A2, and it worked. I really wanted to keep all the pins I was using together so I started investigating what it would take to make B1 and B2 work.
:=
:=After some experimenting, here are two ways I discovered would "fix" the problem with pins B1 and B2:
:=
:=1. Break up and slow down the statement by using:
:= if (input(PIN_B1)
:= {
:= delay_us(20);
:= output_low(PIN_B1);
:= }
:= else
:= {
:= delay_us(20);
:= output_high(PIN_B1);
:= }
:=
:=Apparently the INPUT > OUTPUT sequence is just too fast and slowing it down with delay_us(20)works.
:=
:=2. After some additional tinkering I found that if I added the line #use FAST_IO(B), everything worked.
:=
:=I know this sounds strange but, in STANDARD_IO all I got out of the port was a very short (<1 ms) "glitch" going high. When I changed to FAST_IO it was perfect. Normally I use the 16F876/877 and I have never seen this with them.
:=
:=I am not sure if I would call this a problem with CCS code or not since it works fine on all other pins except B1 and B2.
:=
:=Since it took me 20 minutes to write the code and two hours to figure out why perfectly good code would not work, I thought I would pass this along to save everyone some headaches.
:=
:= Dave
___________________________
This message was ported from CCS's old forum
Original Post ID: 1201

[Steve H.]

The curious part is why only the B1 and B2 pins?
:=when B3, B4 etc work fine. I dont see any difference in B2 and B3 port design that might account for this. If it was just B4-7 I could see a difference with those.

===================

Since the program is not behaving as it was intended, it is not suprising that the result is not as expected. Probably the loading on some of the ports is just enough different, sometimes if the ports are hi-Z even capacitive coupling between pins can pull the pins up and down. Also things like solder flux making a leakage path to ground on some pins but not others. I believe that if you look carefully with a scope you will make sense of what is really happening.

I just spent 10 minutes debugging a VHF oscillator that was working, but then stopped when I changed one part. What did I find? I forgot to rehook the probe to the spectrum analyzer so naturally there was no signal. ;-)

Steve H.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1204