Clock stretching is one of those aspects of I2C that just never got utilized in production chips. EEPROMS you would think would be the ideal candidate for it: when write is enabled, last clock is stretched until the write to memory has occured, but they don't use that, instead you have to poll a memory location.
It's a real shame that SCK is hard driven. As that seems to be only because of the way the Bootloader is written maybe Chip could have his arm twisted to make it soft driven for the Propeller Mk II ?
That would allow multiple Propellers to all boot from the same Eeprom and use those I2C lines for inter-Propeller communications.
I'm not asking for full multi-master I2C support or arbitration, that can be handled after boot-up by user-written I2C objects. Making it work is up to the develper but this would prevent the hardware damage which would currently occur if two Propellers had their SCK lines directly connected.
What makes a clock-stretching protocol difficult for EEPROMS is the way their page-write capability is implemented. To write a page after sending a bunch of data to the on-chip buffer, you have to send a STOP condition. But to do that, SCL already has to be high. At that point it's too late for the chip to hold SCL low to hold the bus.
If writes to an EEPROM were restricted to whole pages of data only, the STOP would not be necessary to signal the end of a block, and the EEPROM could hold the bus after each group of 64 (or whatever page-length) bytes until the write is complete.
I have a feeling that manufactureres are reluctant to implement bus-hold in their slave devices since so few masters support it. In that light, it's kind of a chicken-and-egg problem.
Clock stretch can be deferred to the next time the device is accessed. If the write cycle is complete no stretch, otherwise stretch a clock cycle sometime during the location address. That means further access blocks until the previous write cycle completes.
Leave stretching to the last instant and there's a greater chance a write will have completed before holding up the next access.
That's a very useful technique for Propeller-based I2C Slaves, and far better than guessing how long a delay is needed after each access. All it needs is an I2C Driver which supports clock stretching.
Jimmy W.
Posts: 112
Comments
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
That would allow multiple Propellers to all boot from the same Eeprom and use those I2C lines for inter-Propeller communications.
I'm not asking for full multi-master I2C support or arbitration, that can be handled after boot-up by user-written I2C objects. Making it work is up to the develper but this would prevent the hardware damage which would currently occur if two Propellers had their SCK lines directly connected.
If writes to an EEPROM were restricted to whole pages of data only, the STOP would not be necessary to signal the end of a block, and the EEPROM could hold the bus after each group of 64 (or whatever page-length) bytes until the write is complete.
I have a feeling that manufactureres are reluctant to implement bus-hold in their slave devices since so few masters support it. In that light, it's kind of a chicken-and-egg problem.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
'Still some PropSTICK Kit bare PCBs left!
Clock stretch can be deferred to the next time the device is accessed. If the write cycle is complete no stretch, otherwise stretch a clock cycle sometime during the location address. That means further access blocks until the previous write cycle completes.
Leave stretching to the last instant and there's a greater chance a write will have completed before holding up the next access.
That's a very useful technique for Propeller-based I2C Slaves, and far better than guessing how long a delay is needed after each access. All it needs is an I2C Driver which supports clock stretching.