My conclusions on i2c Master-Slave communciations between Picaxe chips - if the Master sets a value on the slave, and then reads it back, there are four results you can get:
- The value you expected. No more to be said.
- A value of 255 - this probably signifies that the slave isn't there: perhaps the slave chip isn't seeing the i2c, or perhaps there is a problem with SerialIn/SerialOut not having the appropriate resistors, or the rest pin floating.
- A value of one-more-than-the-i2c-address (ie if the address of your slave is 16, then whatever the actual value of the slave byte, it will read as 17) - this signifies a connection problem on your i2c network. For example, I use a crude set of LEDs to check whether the i2c and 12v power (better for longer runs) lines are at the expected voltages - and whilst the LEDs work as expected, while the tester is connected to the i2c network, any attempts at writing/reading by the Master will result in this n+1 response - presumably because the current drain of the LEDs is too great. Another possible cause would be that you had accidentally specified an i2c pin (SDA or SCL) as an output on one of the chips. In my experience, if you usually find that if you get this n+1 response from any address on the i2c network, you will get it from all of them.
- A value of ZERO. In my experience this results from running the hi2cout and hi2cin commands at too high a speed. For example, if your Master is a 40x2 running at em64 with an eternal resonator, you need to drop the speed (I recommend to m8) for the i2c transactions (remember to reset the speed immediately afterwards). If you don't then you will probably find that other 40x2 Picaxe chips running at em64 will perform correctly, but lower-speed chips will fail, either with a zero or a 255
