hi2clast and hi2cflag, when are they valid

#1
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
#2
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.
 
#3
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.
 
Top