Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

i2c transaction question

Status
Not open for further replies.

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
Hello,

Consider the following I2C transactions:

1. The master sends the slave address together with a "write" bit.
2. The slave acknowledges.
3. The master sends a first byte of data to the slave.
4. The slave acklowledges.
5. The master sends a second by of data to the slave.
6. The slave doesn't acklowledge.
7. ?

At step 7, is it mandatory for the master to send either a Stop or a Start condition ?
Is it legal for the master to ignore the NACK and simply proceed to send a 3rd byte of data?
 

At step 7, is it mandatory for the master to send either a Stop or a Start condition ?
Yes according to the specification, see paragraph 7.2 Acknowledge.
 
  • Like
Reactions: shaiko

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Allow me to adjust that transaction list:

0.1 Start project thinking you want to use I2C.
0.2 Make list of all the requirements for a high speed multi-master implementation.
0.3 Start implementing and testing.
0.4 Run around screaming.
0.5 Chuck the entire thing, and replace I2C chippies with others from the exact same vendor, but then with an SPI interface.
0.6 Aaaah, bliss.

Or alternatively
1. The master sends the slave address together with a "write" bit.
2. The slave acknowledges.
3. The master sends a first byte of data to the slave.
4. The slave acklowledges.
5. The master sends a second by of data to the slave.
6. The slave doesn't acklowledge.
7. Well screw you slave, you're out. *desolder*
8. Replace with SPI part.

See, totally legit workflow. Does it show I think I2C is more trouble that it's worth in relation to fpga implementations? ;-)

As for this:
Is it legal for the master to ignore the NACK and simply proceed to send a 3rd byte of data?
As far as I know that is outside of spec. So no, not legal.

On a related note, what do you people use for i2c core? Roll your own? Company already had something lying around? Core from vendors like xilinx (for example the AXI IIC Bus Interface)?

And on a related related note, what makes you chose i2c over spi? Same chip turns out to be cheaper than spi version? There is no spi version? Requiring less io pins on the fpga?
 

On a related note, what do you people use for i2c core? Roll your own? Company already had something lying around? Core from vendors like xilinx (for example the AXI IIC Bus Interface)?

When the time allows - I prefer to write my own...

And on a related related note, what makes you chose i2c over spi? Same chip turns out to be cheaper than spi version? There is no spi version? Requiring less io pins on the fpga?

I agree - I2C isn't as "clean & elegant" as SPI. I'll prefer SPI if I can...
But sometimes you have no choice:

1. Not all ICs have an SPI interface.
2. Sometimes you are given a new project after all the (bad) hardware choices have been made for you.
3. Sometimes you are dealing with a legacy project that was conceived when I2C was considered the best thing after sliced bread...
 

On a related note, what do you people use for i2c core? Roll your own? Company already had something lying around? Core from vendors like xilinx (for example the AXI IIC Bus Interface)?
On one project many years ago we used the I2C core on OpenCores as we didn't want to roll our own. That implementation worked, but we did find a problem in the core in one specific instant. I'm pretty sure the engineer responsible for implementing the I2C reported it to the OC I2C designer. If not you'll have to "rediscover" the bug and fix it (note: I don't have or recall the specifics of the problem).
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top