Hi Chaps.

I concur with Thomas Magin.
The I2C bus is fine for the job.
The spec simply defines how devices are addressed and bits sent.
This is the low-level stuff.

It can't tell you higher level stuff, any more than the RS232
spec can tell you about internet protocols.
The best method would depend on your application.
Tell us a bit more.

Wait-stating by holding the clock line low is valid I2C,
the disadvantage is that nothing else can use the bus for that second.
No problem if there is nothing else needing the bus,
or you can't do anything until you do have the data.

The attention request line method is fine.
Making it an open collector driven line allows it
to be shared with other devices.
An RTC might want to alert the system to an alarm time,
or data capture devices (e.g. teletext chips, packet radio projects)
might wish to alert the system to incoming data.

Having the device ignore its address until it has the data is okay,
and is a method used by EEPROMs. The bus is free for other traffic,
but if all you're going to do is sit there polling for a second then
there's no advantage over simply wait-stating.

Tjaart said this was standard I2C. I don't think the I2C spec says
'this is how devices can/should be polled' as this is device-specific.
I believe it is simply an acceptable application of the I2C bus.
An admirably elegant one as well.

I think I would just poll it once on each cycle of the main control loop.
That would avoid excessive polling choking the bus.

Thomas said:
> The problem is that all the PICs doesn't have the master ability hardware impl
emented.

Any PIC with a couple of I/O lines can be a master.
You don't need special I2C master hardware.
I2C slave hardware IS something desirable though,
as this does make I2C slaves far less work.

> So here is the fourth (and hardest) way: implement a "software master"
> in your PIC which arbitrates the I2C bus on its own.

All I2C masters have to do bit-by-bit arbitration anyway.
This is the data collision detection and backoff.
How your app responds to this is not something the I2C spec
can tell you.

BTW, why does the data take a second to capture?
Perhaps you're counting cycles to measure frequency?
You could get round this by continuously measuring it
and just return the most recent value.