PIC 16f627 using a pin for both input and output

Question

I'm trying to connect two PIC 16f627 chips together (programmed with PICC-Lite) with one I/O pin (RA2, which changes direction at known points) and a CLK pin which is driven by one of the chips.

I originally had it set up so there was a master and a slave. The master would write an 8-bit 'command', the i/o pins' TRIS bits would be flipped and the slave would respond with a 16bit 'answer'.

I've put in (temporary, big) delays to ensure that there are no timing issues.

Writing/reading the command works fine, and both ends flip state (TRISA). However, at this point when the master is to read from a pin it's previously written to, it always reads 0 even if the pin is physically 1!

As far as I can tell, TRISA is set correctly (=set for bit if input), as is CMCON (=7), and I believe the CONFIG word; it is the same for both chips (well, inverted), and input works on the slave... I've also tried to make sure TRISA is never 0 for both chips simultaneously.

What I've tried: - Changing the slave so that instead of trying to send data back, it just toggles the value of it's output pin at long intervals. This can be seen on the output wire, but not on the value of the input pin. - Just passing the state through from the input pin to a different output pin (output remains zero; dummy placement showed that general output on that pin works) - Writing the values of PORTA and TRISA to an LCD - TRISA is correct but PORTA is 0 (even when the wire to the pin is high) - Hooking up the I/O line to an LED shows that it is changing, but the input value on the port is not - Hooking up a voltmeter shows a suitable voltage (equal to V+) - I tried swapping out the Master for a replacement (it figured it may have suffered some physical damage), though this made no difference - I've read that this could be a 'read-modify-write' issue, but I could find no advice for ensuring this is not the case on Pic16s... (there are no LAT ports AFAIK?)

I'm banging my head against the wall on this one. Any hints or ideas would be massively appreciated! I may have to fall back on using two pins (though I was kind of hoping I'd be able to drop in multiple slaves at some point with a single shared I/O line...)

Answer 1

Original post is old, but if anyone else has this problem you might want to post your code. Not saying he/she did, but the original poster might have been reading the latched value of the pin instead of the port value. That is, reading what was last written instead of what voltage was actually being received on the pin.

Keeping good timing between 2 processors is harder the longer the time between a command and a response. Why not implement a protocol where the master and slave are working on every bit. Would cause synchronization to occur 24 times faster than what the scheme OP proposed.

Here's what I've see: The master clocks out an 8 bit command using an open drain pin (I think A4 in this case) tied high through a resistor. But then the master continues to clock out 16 zeros. Oh, forgot to mention that a 1 is a longer lo then tristate (or hi since we are tied hi through a resistor) and a 0 is a shorter lo then tristate (or hi since we are tied hi through a resistor). The slave at the other end received the 8 bit command and is not watching for the 16 zeros. Now, each time the master lowers the line the slave will do nothing if the response from the slave is a zero in that bit position. However, if the response is a 1 the slave will also transmit a lo for for a longer time then the master. Since the master and slave are open drain output and the electrical note created by joining these two pins together is tied hi through a resistor there is no problem. The signal will look like an ordinary 1. And that's what the master software will think. That is, while the master is clocking out 16 zeros the master is reading the port value for zeros and for ones. It all depends on if the slave will stay out because it wants the master to think zero of if the slave will jump in and hold the line down longer causing the master to think, ah, that's a one.

Answer 2

If you only have two I/O pins available and you are thinking about adding more slave devices in the future I'd recommend using a standard protocol instead of making your own. I2C will work well, but you will need to switch to a device that has an MSSP module.