Okay, I can see the changes.
As shown now, the LEDs on the receiving IC will block the data high as they are reversed. The LEDs on the transmitting side aren't a good idea either. If you want LEDs you need to put them from the data line to ground through a resistor, not in series with the connection to cable socket.
Just seen your picture - it looks like you have removed the LEDs, good (I was just about to suggest this.. :-) )
So now it looks as if you have direct connections from IC1 to IC2. If this is the case then if the code (looks reasonable at a glance) and IC wiring are correct then it should work.
If you can confirm with a multimeter that the input pins are seeing a high (or low) voltage and the read value is different, then this would confirm the issue is one or the other of the above. Maybe just apply a known voltage directly and see if you can read that okay)
However, if you are reading different values when the pullups are on/off then that would seem to indicate the read is correct. Try reading a direct voltage and post results, I'm just checking the datasheet for the ICs, will add more shortly.
EDIT - about the pullups:
You can use the internal pullups if you don't mind the line "relaxing" to high when not driven (i.e. default state 1) These are often used for interfacing with open drain buses, or for button to ground, etc to save an external pullup.
If you want to have the lines default state low though, (as is the case for you) you need a pulldown to stop the high impedance floating. Since the IC in question doesn't have internal pulldowns, you need to add them externally.
EDIT - Doh! I've just seen the problem...
In your code you set 1 pin at a time to output and all the rest to inputs. This means that if you have internal pullups on, the undriven pins will default to high! When a pin is set to input, it is high impedance, so effectively it's like disconnecting that end of the line, and the weak pullups will pull the receiving end high.
You need to keep all pins as outputs, and just set one high at a time, this will keep all the pins driven - try this with the pullups on, it should work.
If you know the lines will be driven correctly all the time, you don't need the pullups, but it doesn't hurt to keep them on.
Here is the relevant code (in the intialise registers function):
i2c_start_wait(SLAVE_ADDRESS(0x4E)+I2C_WRITE); // Address Slave 1
i2c_write(0x00); // Set memory pointer to the IODIRA register (IODIRA address is 0x00 - see Page 9)
i2c_write(~(Value)); // Set only one pin at a time as an output and everything else as inputs
i2c_stop();
Change it to:
i2c_start_wait(SLAVE_ADDRESS(0x4E)+I2C_WRITE); // Address Slave 1
i2c_write(0x00); // Set memory pointer to the IODIRA register (IODIRA address is 0x00 - see Page 9)
i2c_write(0x00); // Set all pins as outputs
i2c_stop();
Best Answer
The first thing I verify on a new board, whether it is using an internal oscillator or an external crystal, is that I have the clock frequency set up correctly. This is important because many of the peripherals, such as UART, SPI, I2C and timers depend on it.
The way I verify it is to write a program with a short loop, either in assembly language where I can count the cycles manually, or C as long as you can get a disassembly listing and do the same thing -- and turn an LED on and off. I set up a loop so it executes once a second. I run the code, and check that the LED blinks 60 times in a minute.
As far as peripherals go, the best way to check them is to use an oscilloscope if you have one, and look at the RX line for UART, the CLK, MOSI, and chip select lines for SPI, and the SDA and SCL lines for I2C, and check that the lines are toggling and the timing looks correct.
If you don't have an oscilloscope, you can put LEDs on these lines, and then enable or disable the peripherals, When disabled, most of the lines will be low (LED off), but some will be high, like the RX lead of the UART (LED on). When the peripheral is enabled, most the LEDs should dim, since the lines will be toggling. By running in a loop (disabled/enabled) it is easier to see the difference between on or dim.
For the UART, you can connect the TX line to the RX line as a loop around. You can also connect then to a UART to USB cable, and on the PC real a terminal a program like RealTerm. Besides testing out the interface, this will come in handy for other debugging later.
For other pieces of code, I use multiple LEDs as necessary to show that various paths in the code are being executed. If you have the UART working and connected to a PC, you can sprinkle your code with calls to a subroutine to output a message to show what points the program has reached (or use printf if you have the standard C libraries available). But as Vladimir Cravero points out in a comment below, this can slow your code down some (at 115,200 baud, not too much, since one character time is < 10 µs). But in ISRs and other time critical code, just use LEDs.
As Al Bundy points out in a comment below, in-circuit debuggers can be useful also, particularly if one can set multiple breakpoints, and even more useful if you can breakpoint on a memory location being changed. Not all debuggers have that feature.
However I don't use debuggers a lot unless I have to, for example to look at bits in a peripheral register; or to track down a bug which I can't find by inspection; or to rudimentary code coverage analysis. But in general I like to run programs at their "normal" speed since a lot of issues will usually show up which may not when the program is single-stepped. Most of my programs use interrupts a lot, which interferes with using a debugger.