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 :
2- send(Broadcast address)
3- send (Data to all slaves including the address of the slave that will be allow to answer)
5- READ(Data from selected slave)
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