Using MLX90614 OR is I2C and SMBus compatible?

Question

I am trying to use a Melexis MLX90614 with Atmega8. I have failed in all my attempts till now. I tried sending this sequence

slave address(as 0x00 and 0x5A) --> opcode to read SMBus address 
     --> data byte high --> data byte low

I get a slave address NACK for both SMBus addresses. Is it because I am using an I2C library? I understand we have to give a PEC also, but as the Slave address is NACK'd I don't think the sensor is responding to my commands. I tried using the write opcode and got ACK's for that. So the communication is ok. Can anyone tell me what kind of problem may be here?

Also how would one generate a PEC for SMBus protocol?

I looked at this code and it just sends 0x00 and 0x07 over i2c to fetch two bytes of temperature. How can that be possible? In the datasheet it is specifically mentioned how to read one word and how to write one word. How can this be bypassed?

Answer 1

Theoretically

I2C and SMBUS are essentially compatible as long as you are operating at 100kHz bus speed. The datasheet on page 15 (7.4.3.1.1) suggests to read a register you (as a master) have to do:

Start
SLA+W               (slave acks)
Command             (slave acks)
Repeated Start
SLA+R               (slave acks)
READ data byte low  (you ack)
READ data byte high (you ack)
READ PEC            (you ack)
STOP

The appropriate SLA is 0x5A. Just like with I2C, you will need pullup resistors on the SCK and SDA lines (3.3kOhm should be fine). Command value will depend on what you are trying to do as described on page 16 (7.4.6).

Reality (?)

However, there is a paragraph (7.4.1) on page 13 that says:

In order to provide access to any device or to assign an address to a SD before it is connected to the bus system, the communication must start with zero SA followed by low RWB bit. When this command is sent from the MD, the MLX90614 will always respond and will ignore the internal chip code information.

... now that is a vague description of a specialization of the protocol at best, but it appears to be what the github code is exploiting.

If one is to believe the github code, it is actually illustrating an undocumented protocol behavior. Namely:

START
SLA(0)+W   (slave acks)
Command(7) (slave acks) (writes to the RAM read-address register the value 7 = TOBJ1?)
STOP

START
SLA(0)+R        (slave acks)
READ low byte   (master acks)
READ high byte  (master acks)
READ pec        (master nacks)
STOP

I've seen this "flavor" of I2C interaction before, but I'm with you that it's not described that way in the datasheet.

Sidenote on PEC

As for "how you generate the PEC" it's described on page 14 at the bottom of the page:

The PEC calculation includes all bits except the START, REPEATED START, STOP, ACK, and NACK bits. The PEC is a CRC-8 with polynomial X8+X2+X1+1. The Most Significant Bit of every byte is transferred first.

Basically it's CRC-8-CCITT (see wikipedia) - implementations exist, just google for it, or post a separate question about CRC...