I'm currently working on rewriting some of the code on my I2C driver, and I'm trying to figure out the exact purpose of the STOP condition.

I believe that on a multi-master system, once a START condition has happened, the other masters can't/shouldn't drive the bus until a STOP has happened.

  • But what about on a single master system?
  • Does the STOP condition have any function? What exactly does it do?
  • Because the I2C bus works DC-x Hz, couldn't you just keep doing start conditions and re-start conditions any time you need to send data?
  • What does doing the STOP at the end give you?
  • \$\begingroup\$ @adamLawrence has the right answer. While you MIGHT be able to get away with start + restart + restart, you're not working to the spec and there are enough weird issues with I2C devices that intentionally not sending a STOP is not worth whatever you think you might be saving by not using them \$\endgroup\$ – akohlsmith May 11 '15 at 16:24
  • \$\begingroup\$ @akohlsmith The weird issues with I2C is actually the reason I was asking this question. I was trying to fully understand how the I2C was working. As far as the stop, all the documents I read simply said to do it, not what the effect of doing it was (do it just because that is how you do it). \$\endgroup\$ – w1res May 11 '15 at 16:51

The STOP is an indication to the slave device that communications are complete. It's ingrained in the protocol and spec-compliant slave devices expect to see it, so you simply can't wish it away.

For instance, if you're doing a page-write to a 24AA04 serial EEPROM (up to 16 bytes of data), the EEPROM will stop buffering data and start writing to flash upon receipt of the STOP from the master. You're not obligated to send a full page, so you need the STOP as a clear indication that there are no more bytes coming. (Some EEPROMs will throw away pending transactions if a STOP is not received at an expected/appropriate time, which can lead to some head-scratching debugging problems.)

Some devices also use the STOP to enter a reduced-power-consumption mode, drawing less power until the next START wakes them up.

  • 3
    \$\begingroup\$ It may be worth mentioning that if during a write transaction a typical EEPROM sees any change on SDA while SCK is high other than a valid stop condition, it will abort the transaction and discard any data thus received without writing anything. This greatly reduces the likelihood of invalid writes, but means that code which doesn't generate proper stop pulses won't be able to write anything. \$\endgroup\$ – supercat May 11 '15 at 17:10
  • \$\begingroup\$ +1 Fair point. I added a blurb to my answer. \$\endgroup\$ – Adam Lawrence May 11 '15 at 20:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.