I2C slave can force clock stretching by soft ?

Go To Last Post
7 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I'd like to know if the following I2C schem is possible :
- One I2C Master sends one I2C command of several data bytes (Write command) on the broadcast address, but instead of sending STOP condition, it sends START again and begin a reading sequence with one of the 3 slaves
- 3 SLAVES (3x Atmega328p) receive this first write command in interrupt driven mode (TWI_Vect IRQ), and then 1 of the 3 the read command.

Is it possible that 1 of the 3 slaves engage clock stretching (SCL forced at LOW) by software after any of the ACK condition (more specificaly : for example the last ACK of the write sequence)?

If it's possible, then what will happen :
The master will send the new START to begin read sequence and block ? Or will the master wait releasing of the SCL line before sending the new START ?

How would you do that in software ? I thought that after sending an ACK, I can just disable interrupts by clearing TWIE. Will it be enough to force SCL low until I set TWIE again to continue reading sequence ?

Thanks in advance for your answers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If one or more of the slaves that have been receiving the broadcast write operation are still stretching the last ACK cycle's clock, how can the master even BE finished with that write operation, and embarking on sending a Restart?

All my I2C work has been with bit-banged masters and slaves (the AVR's hardware implementation doesn't meet our needs), so I could be mistaken, but I would hope that the TWI won't signal completion of a "master sends byte" operation until that operation actually completes (inclusive of receiving the receiver's ACK status).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tx for your answer,

So I understand that you confirm : after the slave has send an ACK, this slave can hold the SCL line and block everything on this bus until this slave release it ?

But if at this last slave step (sending ACK), I just disable I2C Interrupts :

then the master will send repeated START, but the slave with disabled interrupt will never release SCL, because the interrupt will not be treated ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But when the slave AVR is sending an ACK, it has received a byte and transmitted the ACK, keeping SCL low, and running the TWI interrupt because it received a byte. I assume you want to read that byte, and after you have handled that received byte in TWI interrupt, you must say to the TWI hardware that you got the byte and it can now release the SCL and continue.

It does not matter if the next thing is start or next data byte. Your slave needs to have interrupts enabled to see that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Jeapael,

I understand that I can keep SCL low after any ACK, and it doesn't matter what will be the next i2c step sended by master (data byte or start condition...) ?

Quote:
you must say to the TWI hardware that you got the byte and it can now release the SCL and continue

And this is done by clearing the IT_FLAG, is that true ?

If that's true, disabling interrupt is enough to keep SCL low ?

Tx again both of you ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't understand what you are trying to do/achieve/understand here.

You don't need to keep SCL low specifically, it is low held low for you until you have had enough time to respond.

If you disable the TWI interrupt, then your software cannot respond to any TWI events and the hardware will keep SCL low indefinitely, blocking the bus for eternity. Master is not able to begin trasnfer of another byte or make start or stop conditions if SCL is held low by a slave.

The point is, the AVR TWI hardware as slave keeps SCL low until the slave software reacts to the event somehow, either in the interrupt routine or polling status in software, because it cannot do it any faster than it can, compared to hardware slave chips that can respond immediately and cannot keep SCL low.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, that is perfectly clear now.
What I try to do is feasible, so.
Many thanks again :)