Searching \ for 'I2C with slow devices' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: massmind.org/techref/i2cs.htm?key=i2c
Search entire site for: 'I2C with slow devices'.

Truncated match.
PICList Thread
'I2C with slow devices'
1998\04\29@021329 by Gavin Jackson

flavicon
face
Hi there

I would like to use I2C to communicate with a 16C84.
The 16C84 will wait until it receives a request for
some data. Once it has received the request it gets
the data it was asked for. The problem I have is that
the data takes about 1 second to obtain. Is there a way
I can get the master that sent the request to wait for
the PIC without the PIC becoming the master and
transmitting the data back.

Does the I2C protocol define a way of communicating with
very slow devices on the bus?

Maybe I2C is not the best protocol, please comment.

Regards

Gavin
--------------------------
spam_OUTvulcanTakeThisOuTspamihug.co.nz
www.geocities.com/TheTropics/Cabana/2625
--------------------------

1998\04\29@025215 by Thomas Magin

flavicon
face
At 16:00 29.04.1998 +1200, you wrote:

Hi,

>the data takes about 1 second to obtain. Is there a way
>I can get the master that sent the request to wait for
>the PIC without the PIC becoming the master and
>transmitting the data back.

one possibility (which I used) is to provide another line for handshaking.
The master is requesting data (by sending a write-command) and if the line
is activated the master will issue a read-command.

>
>Does the I2C protocol define a way of communicating with
>very slow devices on the bus?

Another way is what they call "clockstretching". If a slave gets a
read-command it is allowed to pull the SCL high until it is able to provide
the data. In your case this would result in a 1sec wait for the master. Here
it depends on its hard- and software how to handle this waitstate. The time
this will be take is not defined by the I2C-protocol !

Or: provide a statusregister in your slave. After the datarequest (a
write-command, too) of the master it will poll this register until it is
set. Then the readcommand will follow by the master.

>
>Maybe I2C is not the best protocol, please comment.

The protocol is really fine. The problem is that all the PICs doesn't have
the masterability hardwareimplemented.

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

Regards

Thomas
=8-)

--

**********************************************************
* Thomas Magin                  FON:   ++49-761-4543-489 *
* marquette-Hellige GmbH        FAX:                -507 *
* M&E-FW / Emergency Systems    email: .....maginKILLspamspam@spam@hellige.de  *
* Munzinger Str. 3                                       *
* D-79111 Freiburg / Germany                             *
**********************************************************

1998\04\29@035618 by tjaart

flavicon
face
Thomas Magin wrote:

{Quote hidden}

Doesn't the slave hold the clock line low? I could bewrong - I'll have to RTFM again.

The easiest way could be for the slave to NACK
(not ack) when the master issues its address, and
the master to keep polling until ACK'ed. This is
incidentally the fastest way of writing to an I2C
E2PROM

Both above methods are standard I2C.

--
Friendly Regards

Tjaart van der Walt
tjaartspamKILLspamwasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS .....0832123443KILLspamspam.....wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1998\04\29@080945 by Keith Howell

flavicon
face
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.

1998\04\29@174958 by Gavin Jackson

flavicon
face
part 0 909 bytes
Yip you're right. I'm still on my hydroponics
project and I use the PIC to count the pulses
generated by my conductivity sensor.

I'm going to try the "clock stretching" method
as I have to write the code for both the master
and slave devices and I don't think clock
stretching will be too difficult to implement.

Thanks to all who replied to my posting.

Regards

Gavin
--------------------------
EraseMEvulcanspam_OUTspamTakeThisOuTihug.co.nz
www.geocities.com/TheTropics/Cabana/2625
--------------------------


-----Original Message-----
From:   Keith Howell [SMTP:keithhspamspam_OUTARCAM.CO.UK]
Sent:   Thursday, April 30, 1998 12:06 AM
To:     @spam@PICLISTKILLspamspamMITVMA.MIT.EDU
Subject:        Re: I2C with slow devices

Hi Chaps.

-SNIP-

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.

1998\04\30@045706 by Claudio Rachiele IW0DZG

flavicon
face
                  Status Distribution April 29, 1998 06:50:32

The message regarding "Re: I2C with slow devices" sent on April 29, 1998 06:50:32 was sent by

Status Recipient
         Type                To
         Native Name         KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
         Foreign Native Name RemoveMEPICLISTTakeThisOuTspamMITVMA.MIT.EDU\n\n\nINTERNET



Recipients

Status Reporters
         Type                From
         Initials            CR
         Name Domain         NOTES
         Native Name         CN=Claudio Rachiele IW0DZG/OU=Italy/O=IBM@IBMIT
         Foreign Native Name CN=Claudio Rachiele IW0DZG/OU=Italy/O=IBM\nIBMIT\n\n
         Organization        IBM
         Org Unit 1          Italy
         Last Name           IW0DZG
         First Name          Claudio



Status          769
Explanation     Invalid recipient

X.400 Status    769
Explanation     Router: Unable to open mailbox file D14HUBM1/14/H/IBM mail.box: Server not responding

1998\04\30@081028 by Morgan Olsson

picon face
>> >the data takes about 1 second to obtain. ...

Maybe it is possibly to have the slave continuously (or in interval)
updating its data, so when requested it can directly transmit the most recent?

>Doesn't the slave hold the clock line low?
Yep.
(and thus consuming extra power in the pullup resistors)
I hate powerloss, as a principle...


/Morgan
/  Morgan Olsson, MORGANS REGLERTEKNIK, SE-277 35 KIVIK, Sweden \
\  spamBeGonemrtspamBeGonespaminame.com, ph: +46 (0)414 70741; fax +46 (0)414 70331    /

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...