Detecting I2C READ has occurred

[mortifyu]

Hi Guru's,

This may be a silly question, I have looked around and can't seem to find what I am hoping may be available. Is there something within the PICAXE system that can 'flag' that a I2C READ has occurred?

Providing CODE here would be a bit long winded and unnecessary, but the general basics of what I am doing is...

Via I2C, Master PICAXE sends command byte to Slave PICAXE.

Slave PICAXE then sends appropriate data via HSEROUT to a RF Transceiver.

Quite a bit occurs remotely where the Slave sent the data via RF and then serial data is returned to the Slave again via RF.

Slave PICAXE captures the returned serial data using background receive, processes the data, then makes an output HIGH (C.1) indicating to the Master PICAXE there is now fresh to data to be collected via I2C.

Master PICAXE now acquires the data from the Slave PICAXE using HI2CIN command.

ALL IS WELL, and everything works flawlessly. However, in order for me to now have the Slave PICAXE 'fresh data is available output pin (C.1)' go LOW after the Master has read the data, I have to send another command byte from the Master PICAXE to the Slave PICAXE via I2C to basically tell the Slave the data has been acquired and to make (C.1) LOW again until the next cycle.

I know there is a HI2CFLAG for when there is a data WRITE and I do very much use this.

However my question is, is there a way (Something like a HI2CREADFLAG) to determine that data has been READ via I2C from/at the Slave PICAXE?

Essentially I'd like to be able to READ the Slave data via I2C and have the Slave recognise this has occurred thus make (C.1) LOW on it's own accord.



Pretty sure I have been clear enough with my question, hoping to soon read some 'Guru Magic' answers.



Regards,
Mort.

 

[AllyCat]

Hi,

Essentially I'd like to be able to READ the Slave data via I2C and have the Slave recognise this has occurred thus make (C.1) LOW on it's own accord.

I don't know anything about how the (X2) Slave firmware operates, but I rather doubt if what you want is directly possible. I didn't even know about the HI2CFLAG , for Write operations, but I can see that it could be "useful", or even necessary. However, I would expect the Read (from the Slave) to be a "background" (firmware interrupt) operation in the Slave, which would not be "visible" to the foreground program.

So I suggest the solution may be for the Master to Read the byte(s) and then immediately Write a "flag" (which probably needs to be a full byte) into another register in the Slave's memory. Then the Slave Program would be arranged to poll that register, or perhaps can be interrupted by that HI2CFLAG ? But that seems to be what you are already doing?

I did wonder if the Slave software could check for an "ACK" on the original message to the Master, but that doesn't appear to be what you want? However, on the general topic of validating I2C transfers, you might find PhilHornby's contribution to post #3 of this code snippet thread to be of interest.

Cheers, Alan.

 

[Buzby]

A response sent by the Master, either a pin change or another I2C write, is much better than a Slave-based READFLAG system.

Because the Master has to actively respond, the Slave can be sure the data has not just been READ, but has been acted on as well.

Cheers,

Buzby

 

[mortifyu]

Hi,

I don't know anything about ...

I near fell off my chair when I read this from you Alan. I'd almost bet my lefty that statement from you doesn't exist anywhere else in the entire forum .


Thanks for the info guys, I suspected this was going to be the case and will continue doing as I have done.



Regards,
Mort.

 

[inglewoodpete]

I near fell off my chair when I read this from you Alan. I'd almost bet my lefty that statement from you doesn't exist anywhere else in the entire forum .

Al's very much an M2 man, so the PICAXE as a slave would be foreign to him! I'm the opposite: I rarely use M2s. I even created a "14X2" when the 14M wouldn't do what I wanted!

Once upon a time a long time ago, I had a network of 32 x 28X1 (yes, X1) slaves interworking with a PICAXE master. While the X1 i2c slave chips had a few teething problems requiring 2 rounds of firmware upgrades, the network worked well and was showcased in several locations around the world.

I just had the i2c Master polling through it's list of slaves (using a lookup table) to continually check on their status after each new request for action was sent. No additional signalling wires. The slaves each had a 'status' byte in the scratchpad which they would keep up to date.