It wouldn't need endless clock stretching. Here's a more complete 
picture of what I'm trying to do:

MASTER <=I2C=> PIC1 <=UART=> PIC2 <=I2C=> SLAVE

1. MASTER I2C device sends an I2C start condition.
2. PIC1 (configured as an I2C slave) receives the start and sends a 
START message over the UART to PIC2.
3. PIC2 (configured as an I2C master), receives a START message over 
the UART and sends a I2C start condition to SLAVE.
4. MASTER sends I2C address (7 bits + 1 RW bit)
5. Regardless of the address received, PIC1 holds the clock LOW after 
receiving the 8th clock.
6. PIC1 sends the received address byte across the UART to PIC2
7. PIC2 sends the address byte on its I2C bus.
8. SLAVE either acknowledges or ignores the address byte.
9. PIC2 receives the acknowledge (or lack thereof) and sends a 
message across the UART to PIC1.
10. PIC1 releases the I2C clock and either acknowledges or ignores 
the byte send by MASTER.
11 MASTER receives the acknowledge (or no acknowledge).
12. ... (send the next byte)

This general procedure would be repeated for EVERY byte 
sent/received. This would obviously slow down the transfer rate, but 
that shouldn't be a problem for this application. The I2C spec is not 
explicit about when clock stretching can occur. It implies that it is 
done by a slave after a the slave sends an acknowledge, which is how 
Microchip implements it in PICs by using the CKP bit. What I would 
need to do is stretch the clock before the acknowledge (after the 8th 
clock), which means I wouldn't be able to use the PICs on-board I2C 
facilities; it would have to be completely done in firmware.

Steve Rapinchuk

novakddajac.com wrote:
 > I have seen devices that support bit-level (any bit) clock stretching.
 >
 >
True, but not ALL I2C devices can handle endless stretching. This needs
to be tested carefully

--Bob

 > David
 > http://www.dajac.com
 >
 >
 >
 >> I'm considering a project which requires extending an I2C bus over a
 >> UART, but I'm not sure this is possible. The setup would look
 >> something like this:
 >>
 >> MASTER <=I2C=> PIC1 <=UART=> PIC2 <=I2C=> SLAVE
 >>
 >> 1. A MASTER I2C device sends an I2C start condition.
 >> 2. PIC1 (configured as an I2C slave) receives the start and sends a
 >> START command over the UART to PIC2.
 >> 3. PIC2 (configured as an I2C master), receives a START over the UART
 >> and sends a I2C start condition to SLAVE.
 >> 4. MASTER sends I2C address (7 bits + 1 RW bit) to PIC1.
 >>
 >> Here's the problem: PIC1 can't ACKNOWLEDGE the address from MASTER
 >> because it doesn't know if it is a valid SLAVE address. At first I
 >> thought that clock stretching would take care of it, but the I2C spec
 >> implies that clock stretching can only take place after an
 >> ACKNOWLEDGE (between bytes).
 >>
 >> Am I reading the I2C spec correctly, or is clock stretching allowed
 >> any time during an I2C transfer?
 >>
 >>
 >>
 >> Steve Rapinchuk
 >>
 >>
 >>
 >> --
 >> http://www.piclist.com PIC/SX FAQ & list archive
 >> View/change your membership options at
 >> http://mailman.mit.edu/mailman/listinfo/piclist
 >>
 >>
 >
 >   


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist