picaxe18x and pcf8574AP i2c problems

[hippy]

high 1 : high 4 ; ************************** ????
high 4 : high 1 ; ************************** ????

Interesting. Pin 1 is SDA, Pin 4 SCL so the first would just be a clocked data bit, the second though replicates an I2C Stop signal ( assuming both at zero then SCL high then SDA high ), second time round the loop the first would just keep 1 and 4 high as already set. Maybe try with the first removed ?

I can sort of imagine how it might be kicking the I2C bus and devices back into shape but cannot imagine exactly how that's working or why it would be necessary. If the PCF is holding SCL low for ACK that could explain hanging ( then timeout and reset ) and this would fix it but would also create a short from Pin 1 high through the 'open collector transistor' in the PCF to 0V ( ditto possibly for Pin 4 ). Seems odd though that there'd be no hang after other WRITEI2C.

Using HIGH also disconnects the 18X I2C peripheral so it would possibly it sees the bus lines high - that the TRISB bits do change is what led me to the discovery of the $AE shadow register which allows the 18X 'output only' pins to be made input.

The 18X is a bit odd with respect to I/O; the datasheet clearly states that PORTB pins must be made inputs for UART TX and RX yet when I've used TX on the 18X ( for MIDI ) there's not a single POKE to TRISB or the shadow register yet it worked ! With the HIGH's having been executed and I2CSLAVE setting the hardware for I2C comms there should be no further I2C comms, the PCF should stay with LED's latched on.

The plot thickens.

 

[hippy]

Bangin' away ...

If anyone wants to try it, purely bit-banged I2C for the 18X which should work for PCF8574 and PCF8574AP - edit your actual A2/A1/A0 bits into the top symbols, update the two "dev=".

Completely untested, not even simulated, use at your own risk, blah, blah, etc.

Uses the $AE shadow register from which the genuine TRISB is set to keep all pins as input so SDA and SCL are pulled high by the external R's which must be fitted. When the pins are made output they pull SDA and/or SCL low. Should be entirely electrically safe as per I2C Bus.

 

[eclectic]

I've tried
high 1,4
then high 4,1.

Still works.


“Maybe try with the first removed ?”

But, removing the first “high 4,1”
stops the show.


e

 

[westaust55]

Some mechanism for indicating a reset of the PICAXE has occured has to be added to be able to distinguish when the program is properly looping or resetting. In none of my testing have I seen any 'garbage' other than when a reset has occured.

It is indeed something of a mystery.

I added a couple of lines at the front of my earlier code so first lines are:

Symbol EEPROM_0 = %10100000    ; %1010 = EPROM, 000 = Addr/page 0, and 0 = control bit

SYMBOL expand_2 = %01000110
b0 = 99
debug
pause 4000

                       
Main:                                             ; setup i2c comms to the EEPROM
i2cslave  EEPROM_0, i2cslow, i2cbyte  ; i2cbyte for 24LC16 and i2cword for 24LC256 EEPROM
:
:
:

with no "location" values in the writei2c for the PFC8574's is see b0 go through the values:
99, 1, 0, 64, 99, 1,0,64, 99,1,0,64 . . .

Note that at no time does my code make b0 = 64 but the fact that the 99 keeps returning indicate a program reset.

Added the "0," as a location value and the values for b0 became (with no EEPROM fitted):

99,1,0,2,255, 1,0,2,255, 1,0,2,255, 1,0,2,255, . . .
indicating no reset occurring

so syntax for 28X1 and 40X1 will work as:
writei2c (data, data, . . .)

but for the 18X the syntax MUST be
writei2c location, (data, data, . . . )

even though for the PCF8574 no location is required. It is treated and data and just gets overwrittn very quickly by the "real" data.

It is not the actual PFC8574 itself hardware wise causing the problem, as I experience the same problem with an 18X even without the PCF8574 connected.

 

[westaust55]

tried eclectic program with the 18X.

Works and I find that the order in which you make pins 1 and 4 high is irrelevant but both pins must be made high prior to a writei2c to a PFC8574 IC.

 

[westaust55]

If anyone wants to try it, purely bit-banged I2C for the 18X which should work for PCF8574 and PCF8574AP - edit your actual A2/A1/A0 bits into the top symbols, update the two "dev=".

Completely untested, not even simulated, use at your own risk, blah, blah, etc.

Uses the $AE shadow register from which the genuine TRISB is set to keep all pins as input so SDA and SCL are pulled high by the external R's which must be fitted. When the pins are made output they pull SDA and/or SCL low. Should be entirely electrically safe as per I2C Bus.

Gave your bit-bash code a try and yes it works

 

[westaust55]

Furthermore

the MCP23017 16-bit IO expander (has same slave ID as the PCF8574)
will work without the high 1 : high 4, so this code works on an 18X (Firmware 8.8)

and . . . no hang-ups/lock-ups/resets if the MCP23017 is not connected

;Forum 12 12 09
;http://www.picaxeforum.co.uk/showthread.php?t=14027

#picaxe 18X

sertxd ("Start")

begin:
pause 500
; i2cslave %01110000, i2cslow, i2cbyte ;8574AP 28X1 / 20X2

i2cslave %01000000, i2cslow, i2cbyte  ;MCP23017 or 8574P  with 18X /28X1 /40X1

; No response from 18X  (v. 8.6 or v 8.8)

pause 500
; high 1 : high 4 ; ************************** ????
sertxd ("A ")

writei2c  0,  ($00,$00)    'IODIRA,IODIRB set both port direction register to output for MCP23017
sertxd ("B ")
pause 2000

Main:
; high 4 : high 1 ; ************************** ????

sertxd ("1 ")
writei2c  $12, (%11111111,%11111111) 'turn on all the LEDs (output high)
sertxd ("2 ")
pause 2000
sertxd ("3 ")

; high 4 :high 1  ;***************************** ?????
writei2c  $12, (%00000000,%00000000) 'turn off all the LEDs (output low)
			
sertxd ("4 ")
pause 2000

sertxd ("Done",cr,lf)
goto Main