PIC output is high before being set high automatically

chi-tech-compilermicrocontrollerpic

I am creating a simple pic project that uses a PIC16F877A and I have noticed something that seems odd. Before using any code to change the state of the pins connected to port b, the port b pins are already high. Here is the code I am using in hi tech c with everything else removed to demonstrate the problem. I was wondering if it was normal for the pins to start high before being set in that state. If that is the case I could just set PORTB to 0 at first to solve the problem, I just wanted to make sure that nothing was wrong. This seems to be caused by the line TRISB = 0xFF but I can't understand why since that register only adjusts weather the pin is a input. If anyone requests it I can post my circuit diagram, however I was hoping to avoid having to draw schematic.

#include<htc.h>
#define _XTAL_FREQ 8000000
__CONFIG(UNPROTECT & PWRTDIS & WDTDIS & HS & LVPDIS); 

int main()
{
    TRISB = 0X00;

    while(1)
    {

    }
}

Best Answer

On reset, all port pins are configured as inputs. If they float high, and then you configure them as outputs, they will be driving high. So it's best to set all pins to their default state before writing to the TRIS registers to set them as outputs.

Related Solutions

Electronic – Bit position to bitmask conversion using MPASM directives

I haven't used MPASM before, but does this work?

movlw (1 << O_RED) | (1 << O_GREEN) | (1 << O_BLUE)

Shifting to the left doubles a number.

1 << x == 2^x

Electronic – How does writing to output pins on PORTB affect RBIF interrupt on PIC16F877

The mismatch condition will set the interrupt flag, and reading the port removes the mismatch, but doing so does not clear the flag, you must still clear it manually inside the isr.

From port B circuitry shown in the datasheet (Figure 3-4) you can tell that there is no way that WR (asserted during port writes) could remove the mismatch when the pin is configured as an input (TRIS bit is 1), because the WR signal does not affect anything but the "Data Latch", and the output of the data latch doesn't go anywhere because the tri-state buffer is in high impedance when the TRIS bit is 1.

The information missing here is that a port write also triggers port read, because all writes are really read-modify-write operations. The datasheet says this explicitly about port A, but I suspect it works the same way on port B. This means that when you write to the port, a read is actually performed as well, so RD is asserted, removing the mismatch.

However, the mismatch being removed when you write to the port does not affect the fact that the interrupt is called, because the flag is still set, which is the only thing you need to worry about. Your code does not change, you would still perform a read and then clear the flag when you enter the isr.

You may be wondering if a read or a read-modify-write operation occurs at exactly the same time as the input change may make it miss a mismatch condition. It does not, the flag is should still be set. This is because of the input latch controlled by a signal Q1 (which is not mentioned in the text). It basically keeps the input value for the mismatch comparison during the part of the read cycle in which the RD is being asserted, so that the mismatch is still caught.

Best Answer

Related Solutions

Electronic – Bit position to bitmask conversion using MPASM directives

Electronic – How does writing to output pins on PORTB affect RBIF interrupt on PIC16F877

Related Topic