I2CWRITE and 18F4680

[ecoli-557]

Seems i've overlooked this one..

@ __CONFIG _CONFIG4L, _LVP_ON_4L & _STVREN_ON_4L & _XINST_ON_4L & _DEBUG_OFF_4L

Must be off as the compiler don't use the extended instruction set.

DEFINE I2C_SLOW seems to do weird things here...

EDIT: WHICH WILL BE FIX IF I DARE TO INSTALL THE LATEST PATCH

Well now! We have made SOME progress here. Now the proc is upset that it has not heard back from the 23016! I did as Mr. E suggested and disabled the extended stuff in the proc.
I am working at 20 MHz (tried going to 8 with no help Skimask), so now my LCD message of 'No ACK from I2C device' comes into play. Curious, but re-invigorated......

I am also now using 2.50A PBP still have not located the MPASM 5.20........

All comments and advice is needed however.......

[mister_e]

Unfortunately, latest MPASM version comes with MPLAB on Microchip website.

I never use PBP timeout for I2CWRITE... in case you REALLY want.. well, don't forget what i said... the timeout use a GOTO not a GOSUB. The way you did it, it assume a GOSUB.

Also, use Variable in your I2CWRITE line, numeric value may screw things.

[ecoli-557]

Thanks to Mr. E's eagle eye, I think the disabling of the enhanced CPU did it! I just glossed right over it.
My pins now reflect what I think they should - it still doesn't work - but at least it looks like we have made progress.

Now that I have pins toggling, I now set my sight to the 23016 specifically. The datasheet is confusing and what I use to set it up:
i2cwrite idata,iclock,$20,$06,[$00,$00],errori2c 'Sets both ports as OUTPUTS
pause 20

And to write to it:
i2cwrite idata,iclock,$20,$00,[loop],errori2c
pause 20

may be wrong. According to what I get from the sheet it should be:
address-command byte-data1-data2

My address should be zero (0) as all address lines are at ground and command byte of $06 is IODIR0 and command byte $00 is access to GP0 (zero).

Is this correct?

-Starting to see some sky here

[mister_e]

Try something like this

        CONT con $20
        GP_Port con 0
        LAT_Port con 2
        IODir con 6
        Register var Byte

        Register=IODir        
        i2cwrite idata,iclock, CONT, register,[0,0] ' set all i/o to output
        
        Register=GP_Port 
        i2cwrite idata,iclock, CONT, register,[255,255] ' set all i/o to high
        
        Register=LAT_Port 
        i2cwrite idata,iclock, CONT, register,[255,255] ' set all i/o to high

[ecoli-557]

OK, Thanks again to Mr. E, the data and clock pins are still working with the I2C commands - how interesting that the enhanced bit did that....

The DEFINE I2C_SLOW 1 does not seem to make any difference in my test.

icommand var byte 'The command byte to the MCP23016
i2c_addr var byte 'Address of the 23016

I set up the 23016 at address zero this way:
i2c_addr=$20 'Address 0 for the test????
icommand=6 'Access to IODIR0
i2cwrite idata,iclock,i2c_addr,icommand,[$00,$00] 'Sets device as all OUTPUTS
pause 20 'Cause its the thing to do
(No error modifier Mr. E)

Then I try to push the outputs low as I have 10k pullups on the outputs:
i2c_addr=$20
icommand=0
i2cwrite idata,iclock,i2c_addr,icommand,[$00]
pause 20

The result is that all outputs are high, being pulled so by the 10k sip resistor.....

Any thoughts?

[mister_e]

This mean your device don't accept the first command, so all i/o are set to input, hence why the pull-up bring those pins to high.

Try to install the PBP patch
http://www.melabs.com/support/patches.htm

or just comment the DEFINE I2C_SLOW... or both

[ecoli-557]

I have the patch installed and it is reported as 2.50a by Microcode Studio.

I have put in this code based on what you posted:

define I2C_SLOW
'Constant list
GP_port con 0
LAT_port con 2
IOdir con 6
iaddr con $20
'Variables
ireg var byte
'Set up the 23016
ireg=IOdir
i2cwrite idata,iclock,iaddr,ireg,[0,0] 'Sets GP0.0-GP0.7 as OUTPUTS
pause 20
'Write to the 23016
ireg=GP_port
i2cwrite idata,iclock,iaddr,ireg,[0,0]
pause 20
ireg=LAT_port
i2cwrite idata,iclock,iaddr,ireg,[0,0]

And the ports are all still high, I agree with you, the chip did not accept the first command.

Did I understand your code?

[mister_e]

What if you comment the DEFINE line?

Would help if i had this chip here