Use of HIGH and LOW for pin outputs

[rnuke77]

I am using a PIC 16F877A for a simple process controller. Within bank C I use the outputs (and a resitor) as the base in a NPN transistor, pulling a mechanical relay. I defined the pins as follows for relays 1-4:
Rel1 var PortC.0
Rel2 var PortC.1
...

When I run a simple code such as
HIGH Rel1
Pause 500
HIGH Rel2
Pause 500
HIGH Rel3 ...

The problem is that when Rel2 goes HIGH, Rel1 is automatically going low, same for Rel 2 & 3 and on through Rel 4. When the sequential pin goes output High, the predecessor automatically drops low.

Coded like this, the process works fine
PortC = %00000001
Pause 500
PortC = %00000011
Pause 500
PortC = %00000111
....

What stupid mistake am I making here??

Thanks

[LinkMTech]

List your configs so we can see but I'm guessing along with:

PORTC = %00000000
TRISC = %00000000  ' Set all pins to outputs

Make sure you go through the data sheet on PORTC section and turn OFF all peripherals sharing those pins. From section 3.3:

PORTC is multiplexed with several peripheral functions
(Table 3-5). PORTC pins have Schmitt Trigger input
buffers.
When the I2C module is enabled, the PORTC<4:3>
pins can be configured with normal I2C levels, or with
SMBus levels by using the CKE bit (SSPSTAT<6>).
When enabling peripheral functions, care should be
taken in defining TRIS bits for each PORTC pin. Some
peripherals override the TRIS bit to make a pin an output,
while other peripherals override the TRIS bit to
make a pin an input. Since the TRIS bit override is in
effect while the peripheral is enabled, read-modifywrite
instructions (BSF, BCF, XORWF) with TRISC as
destination, should be avoided. The user should refer
to the corresponding peripheral section for the correct
TRIS bit settings.

Good luck...

[Acetronics2]

Would be much simpler to post your WHOLE code here than let us GUESS what could be wrong ...

Don't you think ???

Alain

[rnuke77]

Sorry, I didnt know how to use the Code: boxes but here is the "non-working" code:

 
DEFINE OSC 4 'Define for 4MHz crystal
DEFINE LOADER_USED 1 ' Boot loader for ICSP
'
' ***** Configure I/O ************************************************
PORTC = %00000000
TRISC = %00000000
Rel1 var PORTC.0 ' Relay1 Transistor input
Rel2 var PORTC.1 ' Relay2 Transistor input
Rel3 var PORTC.2 ' Relay3 Transistor input
Rel4 var PORTC.3 ' Relay4 Transistor input
'
Startup:
Gosub TestRelay1
END
'
TestRelay1:
High Rel1
Pause 1000
High Rel2
Pause 1000
High Rel3
Pause 1000
High Rel4
Pause 1000
Low Rel1
Pause 1000
Low Rel2
Pause 1000
Low Rel3
Pause 1000
Low Rel4
Pause 1000
End

[Bruce]

It definitely sounds like a read-modify-write problem. What happens is the HIGH & LOW commands create BSF PORT,PIN for HIGH, and BCF PORT,PIN for LOW.

This reads the value of the port, flips the bit in question, then writes the whole 8-bit value back to the port. The problem is after you set C0 then set C1. If C0 hasn't transitioned to logic 1 before it sets C1, then it reads-in a logic 0 on C0, then places a logic 0 on C0 when it sets C1.

With PORTC = xx it doesn't read the port first, flip a single bit, then write back, so you don't see this problem.

Normally R-M-W is caused by external capacitance on the pin, which doesn't allow time for the previous pin to transition to the expected logic state before changing the next port pin. But the long delays in between flipping each bit is usually sufficient time for the previous pin to make the transition to the expected logic state.

With 500mS or 1 second in between it should be more than enough time so I would have to suspect a problem in your circuit causing the previous pin you set being read back as 0 on the next BSF op.

This same problem is seen when you don't disable analog features on a port, but there aren't any A/D pins on portc. Pins configured as analog are always read in as zero when the port is read as digital inputs.

It might help if you could post your schematic.

[Acetronics2]

I would add ...

What if you replace the Relays by LEDs + 220 ohms resistors ???

I do hope relays are equipped with their freewheel diode ... and NOT powered from the Pic 5v supply ...

Alain

PS : as the program runs fine aboard my EasyPic5 with leds as outputs ... we could reasonnably suppose it's a HARDWARE issue ...

[rnuke77]

Thanks Guys -
I am scouring through the hardware. Attached is the schematic ...

[rnuke77]

Can really mess up a few days...

Thanks to all for the support. I guess the fact that when written with binary logic the program worked fine - it threw me for a loop and took focus off the hardware. My apologies ...