Post by thread:I2C with slow devices

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_OUTvulcanTakeThisOuTihug.co.nz www.geocities.com/TheTropics/Cabana/2625 --------------------------

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: .....maginKILLspam@spam@hellige.de * * Munzinger Str. 3 * * D-79111 Freiburg / Germany * **********************************************************

Thomas Magin wrote: {Quote hidden}> 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 ! 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 tjaartKILLspamwasp.co.za |--------------------------------------------------| | WASP International | |R&D Engineer : GSM peripheral services development| |--------------------------------------------------| |SMS .....0832123443KILLspam.....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 | |--------------------------------------------------|

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.

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_OUTTakeThisOuTihug.co.nz www.geocities.com/TheTropics/Cabana/2625 -------------------------- -----Original Message----- From: Keith Howell [SMTP:keithhspam_OUTARCAM.CO.UK] Sent: Thursday, April 30, 1998 12:06 AM To: @spam@PICLISTKILLspamMITVMA.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.

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 KILLspamPICLISTKILLspamMITVMA.MIT.EDU Foreign Native Name RemoveMEPICLISTTakeThisOuTMITVMA.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

>> >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 \ \ spamBeGonemrtspamBeGoneiname.com, ph: +46 (0)414 70741; fax +46 (0)414 70331 /