Restoring I2C pins to defaults

N

ncoplin

Member
Hi,

I'm using an 18M2 to drive both an LCD and an I2C EEPROM using some common pins.

Is there a way to turn off I2C functionality and restore normal I/O on the pins so I can control the LCD before and after an I2C action.

1) writing to the I2C bus seems to be Ok as I can afterwards still control the LCD
2) have tried using dirsB to reset pin directions
3) reading from the I2C bus seems to upset things (after restoring directions info goes to the LCD, but its garbled)
4) "HI2CSETUP OFF" seems to reset the picaxe and code after this command doesn't execute
5) only success I have is using an EEPROM location as flag and RESET restart my program after I2C activity to branch to the LCD code. This indicates the problem is inside the PicAxe therefore software correctable

Hoping for a better solution the 5)

Cheers,
Nick
 
Technical

Technical

Technical Support
Staff member
'hi2csetup off' is the correct way to do it, but there is a known bug in the compiler that will be fixed in the next software release, which is due next week.

Are you trying to share a 'serial' and 'i2c' on the same i/o pin? This wouldn't be a good idea at all, as both devices will become confused and the i2c 'open-collector' system will also be affected by the serial connection.
 
Last edited:
N

ncoplin

Member
Hi, thanks,

>Are you trying to share a 'serial' and 'i2c' on the same i/o pin?
No, I am using a 4bit parallel scheme - so I need output only functionality.

Is there any direct way with a "poke" to a register to restore the pin/s until the "off" parameter is fixed.
 
W

westaust55

Moderator
using a pin connected to i2c devices also as a bit for a 4-bit LCD will possibly still appear as clock or data signals to the still conencted i2c devices albeit maybe at a slower data rate and confuse the i2c devices if you manage to "jag"/hit an i2c device slave address such that the i2c device responds then the LCD data may be corrupted as the i2c device pulls the data line low at some point in time.
 
N

ncoplin

Member
The LCD and I2C use a common line for control over who is listening. For the LCD to take note the line (E) needs to be high. This same line is wired to A0=A1=A2=WP on the I2C, hence it should only respond to commands issued to its address (000)

I too thought of a possible contension, but from my debugging its not the I2C chip getting confused, but the picaxe. The software reset fixes the picaxe (should leave the I2C chip in whatever state it was) and this doesn't upset LCD operations.

I've tried writing after the I2C read in order to force he I2C turn its SDA line into listening mode (picaxe now output) - but this doesn't seem to help.

Interestingly, found these comments about the I2C commands. Are they true for the 18M2?
http://www.kranenborg.org/ee/picaxe/i2c.htm
 
N

ncoplin

Member
Interesting... because whilst I2C works great for a 24LC08B my code seems to have serious issues with the larger 24LC64 and 24LC512 chips despite updating to i2cword:

for example:
i2cslave %10100000,i2Cfast,i2cword
writei2c 0,("12345") ' writes to location specified by ascii code for "1"
writei2c 0,(0,"12345") ' correctly writes to location $0000

You can imagine readi2c is completely chaotic!

Using a variable w13 in place of the 0 seems not to help... what's wrong?
 
W

westaust55

Moderator
ncoplin said:
Interesting... because whilst I2C works great for a 24LC08B my code seems to have serious issues with the larger 24LC64 and 24LC512 chips despite updating to i2cword:

for example:
i2cslave %10100000,i2Cfast,i2cword
writei2c 0,("12345") ' writes to location specified by ascii code for "1"
writei2c 0,(0,"12345") ' correctly writes to location $0000

You can imagine readi2c is completely chaotic!

Using a variable w13 in place of the 0 seems not to help... what's wrong?
Click to expand...
"12345" is a 5 bytes string whereas the i2c comms protocol can only handle 1 byte at a time (with an acknowledge bit to be received by the i2c bus master after each byte).

Try using:
writei2c 0, ("1", "2", "3", "4", "5") ' writes to location specified by ascii code for "1" ; place the ASCII code for each character in consecutive EEPROM locations
 
W

westaust55

Moderator
ncoplin said:
The LCD and I2C use a common line for control over who is listening. For the LCD to take note the line (E) needs to be high. This same line is wired to A0=A1=A2=WP on the I2C, hence it should only respond to commands issued to its address (000)

I too thought of a possible contension, but from my debugging its not the I2C chip getting confused, but the picaxe. The software reset fixes the picaxe (should leave the I2C chip in whatever state it was) and this doesn't upset LCD operations.
Click to expand...
Setting the external EEPROM WP pin to low state (0) will not prevent the external EEPROM from the possibility of reacting if the right sequece of bits happens to be transmitted.

While the probability may be low, it cannot entirely be excluded as a possible cause of conflict/faults.
 
hippy

hippy

Ex-Staff (retired)
ncoplin said:
Interesting... because whilst I2C works great for a 24LC08B my code seems to have serious issues with the larger 24LC64 and 24LC512 chips despite updating to i2cword:
Click to expand...
Don't confuse the case of where things were not originally catered for but are now supported and things which should work but appear not to. They are usually very different issues and not related.

ncoplin said:
for example:
i2cslave %10100000,i2Cfast,i2cword
writei2c 0,("12345") ' writes to location specified by ascii code for "1"
writei2c 0,(0,"12345") ' correctly writes to location $0000
Click to expand...
What version of 18M2 Firmware do you have ( View-> Options -> Firmware Check ) ?

There was an issue with original 18M2 firmware with word addressing which has been resolved and with workrounds available.
 
N

ncoplin

Member
westaust55 said:
"12345" is a 5 bytes string whereas the i2c comms protocol can only handle 1 byte at a time (with an acknowledge bit to be received by the i2c bus master after each byte).

Try using:
writei2c 0, ("1", "2", "3", "4", "5") ' writes to location specified by ascii code for "1" ; place the ASCII code for each character in consecutive EEPROM locations
Click to expand...
"12345" works fine - all bytes are in the EEPROM (I checked with a separate dedicated EEPROM reader), they are just starting at the wrong location.
 
N

ncoplin

Member
hippy said:
What version of 18M2 Firmware do you have ( View-> Options -> Firmware Check ) ?

There was an issue with original 18M2 firmware with word addressing which has been resolved and with workrounds available.
Click to expand...
I think its the early one 2A? I bought them as soon as the chip was released. Could you please point me to the workarounds?
 
You must log in or register to reply here.
Top