I2C custom BROADCAST+READ on multiple MCU slaves

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

Hi all,

I'm about to write my custom version of the i2c as a communication protocol between :
- 1 Master MCU, sending a broadcast command to all slaves.
- several Slaves MCU (atmega328p) with the same i2c code onboard. After each broadcast command from the Master, one (and only one) slave will answer (one slave after the others).
- there will be no other i2c compliant device on the bus, so it's not a problem if the result is not exactly compliant.

All the slaves are running other time consuming tasks, and should allow the minimum time to i2c, so first, I presume I should use an interrupt driven schem ?

Could you please tell me if this schem is OK ?

One transmit/read from the Master point of view :
1- send(START)
2- send(Broadcast address)
3- send (Data to all slaves including the address of the slave that will be allow to answer)

4- send(REPEATED_START)
5- READ(Data from selected slave)
6- send(STOP)

Questions about above points :
2- Concerning using boadcast command, the ACK bit will be sent by all the slaves, is that true ? So if one of the slave is pulling low to send an ACK, you can't really know if the other slaves haven't received the command ?

Because there is other tasks with higher priority than the i2c on the slaves, I'd like to use clock stretching to slow the communication if needed.
- I believe it's possible in the 4-5-6 section, is that true ?
- But is it possible too in the 1-2-3-4 section ?

Thanks for all your answers, comments or advices on this points

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

Hi!

neoirto wrote:
Could you please tell me if this schem is OK ?

It is Ok.
Quote:

Questions about above points :
2- Concerning using boadcast command, the ACK bit will be sent by all the slaves, is that true ?

Yes, it is.
Quote:
So if one of the slave is pulling low to send an ACK, you can't really know if the other slaves haven't received the command ?

Yes.
Quote:

Because there is other tasks with higher priority than the i2c on the slaves, I'd like to use clock stretching to slow the communication if needed.

It is not needed. If even one slave do not processed ISR, then SCL remains low.
Quote:

- I believe it's possible in the 4-5-6 section, is that true ?
- But is it possible too in the 1-2-3-4 section ?

Its are all possible.

Ilya

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

Thanks for your quick answer,

Quote:
It is not needed. If even one slave do not processed ISR, then SCL remains low.

I'm not sure to understand : SCL is pulled low by all slaves while SIGNAL(TWI_vect) hasn't return from all slaves ?
I was believing SCL was driven by the MASTER all the time, except during clock stretching ?

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

Hi!

neoirto wrote:
Quote:
It is not needed. If even one slave do not processed ISR, then SCL remains low.

I'm not sure to understand : SCL is pulled low by all slaves while SIGNAL(TWI_vect) hasn't return from all slaves ?
I was believing SCL was driven by the MASTER all the time, except during clock stretching ?

Yes. There is clock stretching until slave reset TWINT flag in TWCR register.

Ilya

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

This is something I missed, so.
And this is a very well written protocol...

In the case of a non-broadcast command, every device is holding the SCL low, or is it only the "addressed" device which has this behaviour ?
And in the case of a broadcast command ?

Thanks again Ilya