I am trying to interface to a DS1337 which uses the I2C bus. I have never used the IC2 bus before. The datasheet says that an ack bit needs to be sent after receiving data. Is this automatically handled by I2C or something I need to do? How do you send just one bit?

Acknowledge: Each receiving device, when addressed, is obliged to generate an acknowledge after the reception of each byte. The master device must generate an extra clock pulse that is associated with this acknowledge bit.
A device that acknowledges must pull down the SDA line during the acknowledge clock pulse in such a way that the SDA line is stable LOW during the HIGH period of the acknowledge-related clock pulse. Of course, setup and hold times must be taken into account. A master must signal an end of data to the slave by not generating an acknowledge bit on the last byte that has been clocked out of the slave. In this case, the slave must leave the data line HIGH to enable the master to generate the STOP condition.

Data transfer from a slave transmitter to a master receiver. The master transmits the first byte (the slave address). The slave then returns an acknowledge bit, followed by the slave transmitting a number of data bytes. The master returns an acknowledge bit after all received bytes other than the last byte.

 

Ha! Right in my wheelhouse..

In short, the ACK bit is generated automatically by the I2C peripherals in use. Who generates it and when depends on a few things.

First, the DS is an I2C slave i.e. it does not generate SCL. For 7 bit I2C: A slave sits around waiting for a 'S'tart condition then expects a 7 bit address + an R/W bit indicating the slave is being read or written. All slaves on the bus do this. After sending the 8 bits (7 address +1R/W) the master releases SDA i.e. and it will be pulled up by the resistor on the bus. The master then issues one more clock on SCL (the ack/nak clock). When a slave sees the its 7 bit address + R/W it grabs SDA and pulls it low for that one SCL (ACK). After that, the slave releases SDA so that the master can send the next byte(s). Note that if there is no slave at the address, no slave will grab SDA low when the master generates the 9th clock and that is a NAK. The master will then abort the transfer (no slave) and generate the sto'P' condition.

For writes, if a slave acknowledges, then the master continues to clock SCL, shifting 8 bits out. After each byte, the master releases SDA and issues the 9th clock. When the slave has received the data (and wants more) it pulls SDA down for that clock (ACK).

If a slave wants to stop the transmission, it leaves the bus pulled high for that clock (NAK). If OTOH, the master is done, the slave will have issued ACK and released the bus. In either case, the master then generates a stoP condition to terminate the transaction and release the bus.

For reads, ACK is a bit different. The master again sends Start and addresses the slave (with R/W bit high). The slave ACKs then grabs SDA. The master then sends 8 SCL and the slave toggles SDA to allow the master to clock in the data. On the 9th bit, the SLAVE releases SDA and the master grabs it and sends the 9th SCL to ACK the slave's transmission. ACK in this context tells the slave that it can grab SCL again in preparation for the master to clock in the next byte. When the master has had enough, it does NOT grab SDA after the received data byte letting it pull high for the 9th SCL. This is a NAK and tells the slave that its transmission is done and not to grab SCL. The bus is then free for the master to send the stoP condition.

Writing and reading can be combined into one transaction using the rS (repeat Start) condition. After a master makes its initial write to the slave, instead of sending a stoP, it raises both SDA and SCL then sends another Start (rS) with R/W set to read. After reading the data, the master sends stoP normally. This sequence is often seen in addressing an I2C EEPROM i.e. the write sets the address to read from and the read sends the data. Not sending stoP in between the write and read ensures that the bus is not taken over by another master in the middle of the transaction.

If you are using an I2C peripheral in a uC with master capability, all or most of the ACK/NAK is taken care of automatically on some level.

Hope that helps. Have fun.

 

The master device makes the clock. Who makes the ACK bit depends on which way the data travels.

On a write (master->slave) the slave controls ACK to say it got the data.

On a read (slave->master) the master controls ACK again to say it got the data.

Many people's I2C code on the web ignore the ACK receipt of the bit. That is a mistake as it tells you data is valid or a device is actually present on the bus.



Aside: I can't understand the popularity of the DS1337 for use in new designs. There are so many better chips since it was developed many many years ago.

 

Thanks to the both of you for all of the great details.

I did find some sample code and it is helping me to understand how this all works.

Perhaps it is just bad code or something I am not understanding.

What he does is setup to read the seconds (I am starting to understand what needs to happen there with your help and the sample). What I don't understand is he reads the byte (the seconds) and then immediately sends an ACK. He never really checks anything. I am used to ACKs being sent after a CRC check. Of course with 1 byte, a CRC would be kind of silly. Is the ACK in this case just to tell the slave, "yeah I got a byte"?

 

Is the ACK in this case just to tell the slave, "yeah I got a byte"?

Yup, at this level, that's pretty much it. The slave will keep control of SDA (because the master's ACK says it is going to read another byte). Of course, if for some reason you didn't like the data, you could send NAK then stoP to terminate the transaction. NAK will tell the slave NOT to regain control of SDA so that the master can send the stoP (or rS).

Note that at the end of reading the sequence of bytes, the master must NAK the last one so that the slave will free SDA for the stoP condition.

 

Is the ACK in this case just to tell the slave, "yeah I got a byte"?

Answered and asked:

In a read (slave->master) the master controls ACK again to say it got the data.

Note that at the end of reading the sequence of bytes, the master must NAK the last one so that the slave will free SDA for the stoP condition.

As some devices may need the NAK it is good practice, though I don't think I've ever found it essential as the stop signal ends the sequence anyway.

 

As some devices may need the NAK it is good practice, though I don't think I've ever found it essential as the stop signal ends the sequence anyway.

Hmmm...Maybe some simple slaves (EEPROM?) don't output the next data bit (after ACK) until SCL goes up again. You also might get lucky if the next bit to be shifted out is a '1'. However, if the slave takes SDA after the falling edge of the ACK clock and the next data bit is '0', its perfectly within spec to SDA and prevent stoP.

The state-machine logic in some slaves can also be confused if things are not just so. Some I've used (LM35, some EEPROMs) get 'lost' if you don't toe the line on the I2C spec, especially static ones that rely on SCL for all clocking (as opposed to an internal uC peripheral).

That said, I've done what you described and gotten away with it in some situations..

 

But is back just used to let the slave know the master has read the byte?

Also can I have more than one i2c device as long as they are different devices since the device has an address?

 

Yes to both questions - assuming 'back' is ACK.

 

Hmmm...Maybe some simple slaves (EEPROM?) don't output the next data bit (after ACK) until SCL goes up again.

I would not argue the point as it was a few years back I was working with some device and I did not NAK the last byte and the thing worked. I may have been lucky as you suggest.

As we both agree, NAKing the last byte is proper and preferred.

 

Yes to both questions - assuming 'back' is ACK.

Lousy spell corrector on Android!