I tried a few more tests tonight with a 24LC16B EEPROM and two PFC8574 ICs:
Here is the
basic code:
Code:
Symbol EEPROM_0 = %10100000 ; %1010 = EPROM, 000 = Addr/page 0, and 0 = control bit
SYMBOL expand_2 = %01000110
Main: ; setup i2c comms to the EEPROM
i2cslave EEPROM_0, i2cslow, i2cbyte ; i2cbyte for 24LC16 and i2cword for 24LC256 EEPROM
writei2c 0, ($40, $41, $42, $43, $44, $45, $46, $47 )
Pause 20
debug
b0 = 1
b1 = 1
b2 = 1
b3 = 1
b4 = 1
b5 = 1
b6 = 1
b7 = 1
debug
pause 1000
i2cslave expand_2, i2cslow, i2cbyte
b0 = $0
debug
i2cwrite (b0) 'turn off all the LEDs (output low)
b0 = $2
debug
i2cslave EEPROM_0, i2cslow, i2cbyte
readi2c 0, (b0, b1, b2, b3, b4, b5, b6, b7 )
debug
Pause 1000
i2cslave expand_2, i2cslow, i2cbyte
b0 = $FF
i2cwrite (b0) 'turn on all the LEDs (output low)
debug
Pause 10000
goto main
The results are:
1. with the EEPROM and PFC8574 all connected and
NO writei2c statements rem’ed out, the program locks up at the line
i2cwrite (b0) 'turn off all the LEDs (output low)
I see b0 go to 1 and back to 0 but next changes to the value 2. Instead a complete reset of the program occurs.
2. with the EEPROM and PFC8574 all connected and the IO expander writei2c statements rem’ed out, the program runs and I can write and read from the EEPROM (changed data to EEPROM and always saw the latest data written into EEPROM)
This demonstrates that having the PCF8574’s connected to the i2c bus does not disrupt the i2c bus as I can still write and read to other i2c devices
3. with the EEPROM removed and PFC8574 connected and the IO expander writei2c statements rem’ed out, the program runs and as expected I read $FF from the EEPROM address
This demonstrates that writing and reading to/from an non existent device (ie the missing EEPROM) does not lock up/reset the PICAXE
4. with the EEPROM connected and the PFC8574’s disconnected and all writei2c command enabled the program locks up at the line
i2cwrite (b0) 'turn off all the LEDs (output low)
I see b0 go to 1 and back to 0 but next changes to the value 2. Instead a complete reset occurs.
5. I then added a supposedly unnecessary location byte to the writei2c commands for the PFC8574’s
That is: i2cwrite
0, (b0) 'turn off all the LEDs (output low)
And the program now cycles through without the PCF8574’s connected/
6. Reconnected the PCF8574’s and left the location bytes in the IO expander writei2c commands and . . .
The program continues to run
Still getting garbage at the SERIAL OUT pin of the 18X as seen on the PC’s terminal window and no LED activity on the PFC8574’s when the IO expander writei2c commands are not REM’ed out.
If I change the IO expander Slave addresses to %01111110 even though they are non existent at this address on my test rig,
(a) the program does continue to loop through with no writei2c commands REM'ed out
(b) I still see garbage via the SERIAL OUTPUT pin to the PC terminal window.
For some passes of the program tonight I added an extra 220uF cap to the power supply which provided no improvement.
Conclusions (maybe),
the 18X writei2c commands seemingly still need a minimum of 2 bytes whereas the 40X1 writei2c commands will work with a single bytes.
there is a problem with the 18X when a slave device for a connected PFC8574 (and seemingly PFC8574A) is used.
I have between last night and tonight confirmed no problems reading and writing to EEPROM and DS1307 RTC - even with PFC8574 connected
There is no problem addressing PFC8574's with the 40X1.
= = = = = = = = =
EDIT:
Found this thread where 18X with Firmware 8.4 worked with PCF8574, but firmware 8.5 did not work
http://www.picaxeforum.co.uk/showthread.php?t=3047
From the Firmware text file with the PE, supposedly, firmware V8.6 “ADDED SINGLE BYTE READI2C/WRITEI2C SUPPORT"
Some with Firmware 8.7 indicate problems akin to what I am finding with PCF8574 chips.
I have 18X with firmware revision 8.8 (According to PE V5.2.7). Both chips both a few months back about a month apart and from different Australia retailers.
But the Firmware.txt file with PE V5.2.7 does not list Firmware V8.8
