I2C Digital Waveform (IDW)

[Christian_L]

Please provide feedback, comments, and questions on the I2C Digital Waveform Reference Library in this thread.

- David

(posted by Christian on behalf of David)

[jahannah]

I just started a contract today where I need to implement the I2C/SMB bus with a NI-6552 HSDIO PXI instrument.  I feel like I just hit a grand slam when I found this code.  I will be implementing this code to formulate I2C packets in the days to come.  I will let you know how it turns out.

Anyone out there have any experience implementing or additional comments concerning the implementation of I2C using HSDIO?  In particular, I am interested in the handshaking aspect--using the ACK or NACK to trigger the transmit of the next packet content from the master.

James Hannah

RF Test and Measurement Solutions

[David S.]

Hi jahannah -

I just posted that article yesterday :)  Glad to see it's going to be useful out there.  I'm also working on a Reference Application for using the IDW library with a PXI-6552 to conduct a parametric test on the I2C bus.  I'll link it from here when it's done, though I have to admit that it could be awhile.  In the meantime, if you have any specific questions about how to use that device to get your test running, feel free to post them here.  I'll help out as I can.

In direct response to the ACK/NACK question, I haven't gotten to look into this too much yet.  But I anticipate simply using the Hardware Compare (HWC) engine on the 6552 to find out whether the slave ACK'd.  You can use the Hardware Compare - Response Only example VI to see how to check the slave's response.  If you transmit a packet and no error shows up afterward, the slave ACK'd and you can build/send the next packet.  If an error pops up, you know it NACK'd and can act accordingly.   If you want more resolution than just the presence of an error, you can use the niHSDIO HWC Fetch Sample Errors VI to get the actual sample location of any given error.  This tells you when the slave(N)ACK'd.

If this is an ATE system, you may also consider building packets that don't listen to the slave's response message.  The Add Data Byte VI will add a compare sample for every bit when used in Rx mode.  If you put it into Tx mode with 0xFF as the data though, it'll omit that sample and just tristate the line during the bit times.  This lets the slave send its data while the master ignores it.  It also reduces the number of compare samples you have to generate, which will decrease your memory requirement on the 6552.  Here's an image of the edits you'd make to the IDW Receive - Multi Byte VI to do this.

Message Edited by David S. on 11-04-2008 10:06 AM

[Anne_Z]

David,

I tried to post a reply, but it does not look like it made the trip.  This is a retry.  Attached is my current (preliminary) code for Multi-Byte Write.  It works great.  However, it ignores the acknowledge, and I don't want it to.  To get this code to work, I took your example and changed the enum on the BD from ListenACK to SendNACK, which was required to get the L's out of the write pattern.

What I specifically need from NI, is for you to look at page 11 of the TSL2560 data sheet (last item) at http://www.taosinc.com/ProductDetail.aspx?product=23  and provide working examples of Write Byte with ACK and Read Byte with ACK.  I will also read and write words, but I can use the byte VIs as a template.  Please post the code to this forum, look up NI Service Request Number 1268003 to get my phone number, and call me to let me know when the code is available. (I will be away from my email client during business hours.)

This is time critical, so any help that you can provide will be appreciated.

Thanks,

James

[Anne_Z]

David,

I forgot to mention that I am using a PXI-6552.

James

[Anne_Z]

Paul,

Here is the missing code.

James

[Anne_Z]

Paul,

I changed the Close VI to append conditionally.

James

[David S.]

 Hi "Anne" -

It may be that my recommendation on ignoring the data coming from the slave was confused with the acknowledge bit coming from the slave.  The latter should absolutely be checked with a compare sample, to make sure the slave is responding to the master appropriately.

If you send a NACK to the slave device, the master is controlling the SDA line.  It doesn't make sense to listen to that line with a compare sample, since you already know its value will be Z when the master sends NACK.  It only makes sense to compare the line's state against an expected value when the slave is sending ACK/NACK.  In this situation, choose the Listen ACK or Listen NACK state for that VI. If you look at the IDW Transmit - Multi Byte example, you can see that I'm listening for an ACK from the slave in every byte.  This inserts an "L" sample into every ACK bit, as expected.

Although I'm absolutely looking for feedback on this component library and want to help people understand how to use it, I won't be able to write code for your slave for you.  If you need hired help developing your project, I recommend contacting one of NI's Alliance Members.

[Brueller]

Hello Christian,

thanks for that library, it is very usefull.

But how can I receive data over I2C with your library?

Can you give me a small example or explain how I have to implement that?

Thanks

[David S.]

Hi Brueller -

The example program IDW Receive - Multi Byte.vi that's installed by the component builds a waveform that compares the slave's message against an expected response.  As I explained to jahannah above, you can look at the HSDIO examples to learn how to fetch the locations of sample errors. Then simply compare them against your expected message to determine the data that came back from the slave.  I recommend using 0x00 as your expected byte, so every error is known to be a '1'. This lets you rebuild the response packet without having to check each bit against the expected value.