hi2clast and hi2cflag, when are they valid

Just trying to get a better understanding of when these two values become valid. I have a 20x2 as slave and a Raspberry Pi as master (using Python and SMBUS).

To my mind the Picaxe Manual is a little vague about these two flags. To clarify:

When I write sequential bytes onto the slave hi2cflag is set by each byte?
for control in range (1,num_controls):
i2cb.write_byte_data(Slave,control,controls[control])

When I write a word onto the slave hi2cflag is set ... when?
for control in range (1,num_controls):
i2cb.write_word_data(Slave,control,controls[control])

If I don't clear hi2cflag what happens?

When is hi2clast set and to what address. If it is set after each byte and a byte can only be sent after hi2cflag is clear isn't i2clast limited to an increment of one byte?​

Would appreciate anyone being able to clarify operation in this area because for my application set-up at the present I sometimes need to write an array, and sometimes just one byte. I am finding that if I don't clear hi2cflag the slave effectively drops off the bus and it's address becomes invalid. My code needs adapting but right now I am not sure how best to change it.
 

hippy

Technical Support
Staff member
Testing was done a long time ago, and I haven't used 'hi2cflag' or 'hi2clast' much, but my understanding is that 'hi2cflag' will be set for every byte received over I2C and placed into scratchpad, and 'hi2clast' is updated to the address the received byte was written into.

Sending multiple bytes should set both as each is received. My understanding that at the end of a multiple byte send, when all have been received, 'hi2clast' will be set, and 'hi2clast' will indicate the address the last of those bytes was written to. It should be reasonable easy to check that is the case.

I am not sure why the slave drops off the bus. It should be possible to ignore all incoming I2C data, never clear 'hi2cflag', and it should all keep working.

The issue may have something to do with what is sending the I2C data rather than the PICAXE.
 

inglewoodpete

Senior Member
I have used 20X2s and 28X2s is I2C slaves. I have used hi2cflag to trigger interrupts on some (not all) projects but not used hi2clast. I have never had problems with a PICAXE i2c slave "dropping off the bus", so doubt that the X2 is at fault here, unless it is code related. Some very early firmware versions did have issues with i2c but these were resolved over 5 years ago.
 

grim_reaper

Senior Member
I realise it's nearly four years on, but I've been playing with I2C (20X2 master and 20X2 slaves) and been through many of these issues.
What I discovered with my particular set-up is that the slave may appear to drop off the bus, but in fact it was just too busy to respond to the master - I have a lot of ReadTemp12 statements in the slave, and as stated in the manuals, internal 'soft' interrupts (I2C reads) are ignored during statements such as ReadTemp12.
My current solution has been to enable interrupts for the master writing to the slave (as per the hI2CFlag bit mentioned above) and simply pause the temperature reading code for half a second to let the master read back all the slave data.

I hope that helps someone in the future!
 

lbenson

Senior Member
I have a lot of ReadTemp12 statements in the slave, and as stated in the manuals, internal 'soft' interrupts (I2C reads) are ignored during statements such as ReadTemp12
Another option is to initiate the temperature read with the one wire command, and then read the result after an appropriate delay (one second or thereabouts)--interrupts would not be ignored.
 

Aries

New Member
Another option is to initiate the temperature read with the one wire command, and then read the result after an appropriate delay (one second or thereabouts)--interrupts would not be ignored.
I also have a 20X2 slave reading (I think it is 11) DS18B20s, using READTEMP12 via a multiplexer. Looking at the Picaxe manual, it says that the one-wire commands OWIN and OWOUT as well as READTEMP12 conflict with background I2C. I have experienced the same as GR - the master loses communication with the slave and the I2C bus often hangs. Would the OWIN/OWOUT method for readtemp (as described in the Picaxe manual) avoid the problem altogether, or just make it less likely?
 

tiscando

Senior Member
I realise it's nearly four years on, but I've been playing with I2C (20X2 master and 20X2 slaves) and been through many of these issues.
What I discovered with my particular set-up is that the slave may appear to drop off the bus, but in fact it was just too busy to respond to the master - I have a lot of ReadTemp12 statements in the slave, and as stated in the manuals, internal 'soft' interrupts (I2C reads) are ignored during statements such as ReadTemp12.
My current solution has been to enable interrupts for the master writing to the slave (as per the hI2CFlag bit mentioned above) and simply pause the temperature reading code for half a second to let the master read back all the slave data.

I hope that helps someone in the future!
I second that. I have a 28X2 hooked up to the serial and i2c pins of a Raspberry Pi, the serial for reprogramming and telemetry, and i2c for setting values in the 28X2's scratchpad (temperature thresholds, time delays, PID control gains etc.). It runs a solar thermal system and has a lot of OWIN, OWOUT (for DS18B20 temperature sensors) and other such commands that pause the i2c slave background receive, so often I have to send the same i2c byte from the Pi several times before it succeeds. And then even if the byte is sent successfully (i.e. the picaxe responds with ACK), it does not always reach the scratchpad, so I have to read-verify the byte as well to make sure it was properly written. Also, the clock frequency must be at least m8 (default) or greater for the 28X2's i2c background receive to work. (Why the **** do OWIN and OWOUT still run at 4 MHz on an X2? I was wondering why the PWMOUT frequency was fluctuating.)
 
Top