topic Re: I2C Digital Waveform (IDW) in Components

I2C Digital Waveform (IDW)

Christian_L — Tue, 24 May 2011 18:56:48 GMT

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

- David

(posted by Christian on behalf of David)

Re: I2C Digital Waveform (IDW)

jahannah — Tue, 04 Nov 2008 02:40:07 GMT

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

Re: I2C Digital Waveform (IDW)

David S. — Tue, 04 Nov 2008 16:06:24 GMT

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

Re: I2C Digital Waveform (IDW)

Anne_Z — Tue, 04 Nov 2008 23:43:05 GMT

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

Re: I2C Digital Waveform (IDW)

Anne_Z — Tue, 04 Nov 2008 23:44:19 GMT

David,

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

James

Re: I2C Digital Waveform (IDW)

Anne_Z — Wed, 05 Nov 2008 16:13:59 GMT

Paul,

Here is the missing code.

James

Re: I2C Digital Waveform (IDW)

Anne_Z — Wed, 05 Nov 2008 16:22:17 GMT

Paul,

I changed the Close VI to append conditionally.

James

Re: I2C Digital Waveform (IDW)

David S. — Tue, 15 Apr 2025 13:53:50 GMT

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.

Re: I2C Digital Waveform (IDW)

Brueller — Fri, 28 Nov 2008 21:27:33 GMT

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

Re: I2C Digital Waveform (IDW)

David S. — Sat, 29 Nov 2008 20:25:36 GMT

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.

Re: I2C Digital Waveform (IDW)

fr@nk — Sun, 08 Feb 2009 03:43:34 GMT

I saw your I2C VI suite and and would like to try talking to a device using them. How do I direct the DWDT waveform to physical digital I/O pins of a DAQmx device?

Re: I2C Digital Waveform (IDW)

David S. — Mon, 09 Feb 2009 20:49:25 GMT

Hi Frank -

The IDW library was designed for use with the NI 655x devices. Specifically, it takes advantage of two features on these boards:

Per-cycle tristate: To fully communicate on an I2C bus, you have to be able to drive an open-collector output and read an input on the same pin. The buffers on the 655x can be tri-stated in a single clock cyce, allowing them to both drive data passively and sample on the very next clock cycle.
Hardware compare: IDW builds waveforms that use single-bit compare states (H and L) to check a slave's response on the bus. This offloads processing the response data from the system software, making the application much more efficient.

You may be able to edit the IDW source code to work with a DAQmx-based device, but you'll have to work with only a subset of the functionality. Here are some pitfalls and workarounds I can see:

The only other clocked DIO device that supports open-collector outputs is the 6534. If you use a DAQ (E-, M-series, etc.) or another 653x device, you'll be stuck with actively driven outputs. This means that you won't be able to listen to the slave's responses (data and ACK) while the DO session is active.
No other device supports the compare and tristate states (L, H, X, Z, V, T) in a waveform. You'll have to either edit the IDW code to generate an active-drive waveform (1 and 0 only) or write a find-and-replace function that changes the Z's to 1's.
Without per-cycle tristating, you'll have to tell the DO session to tristate the buffers immediately after generating each segment of the waveform, so you don't interfere with the DUT's attempt to respond with an ACK bit or a data byte.
You can trigger the acquisiton (DI) task off the generation (DO) task to capture an ACK bit after you've sent data -- or to capture a data byte after the first ACK bit. Because of the above requirement of ending the DO session after generating the waveform though, this means that you'll have to stop-and-restart the sessions to transfer every byte. Some chips have a maximum limit to the amount of time between clock pulses; make sure you won't violate it waiting for the software to restart the sessions.
Without hardware compare, you'll have to write a bit-banging funciton to parse the acquired waveform and extract the valid bits that were sent by the slave.

It's not an impossible task, but it's largely simplified by the 655x's features.

Re: I2C Digital Waveform (IDW)

fr@nk — Mon, 09 Feb 2009 21:30:34 GMT

Hi David,

Thanks for the response. I think I'll use a micro with hardware I2C for this, sounds like it will be easier but I have a question. I downloaded the 3 examples ( IDW Transmit, Receive and Combined and opened all of the VIs to see what was going on. Each of the VIs add the locis state and timing information for an I2C function (Start, Ack, etc.) and append it to 'Data Type of Wire and when all the functionality has been appended the data is converted to a waveform and displayed. Where is the interface to the actual hardware I/O port lines for the SCL and SDA signals implemented? I didn't see any hardware task or physical channel hooks.

Frank

Re: I2C Digital Waveform (IDW)

David S. — Mon, 09 Feb 2009 21:42:24 GMT

Hi Frank -

There aren't any. I had to scope this project to some degree, and since there are so many hardware options and two different drivers (NI-DAQmx and NI-HSDIO) available for a task like this, I decided to provide a tool that just helps you build a digital waveform (DWDT) for this protocol. It doesn't do any of the work of configuring your specific hardware with your preferred driver; making an encompassing tool for all the existing permutations alone would be really hard. And supporting such a tool for future releases of NI hardware and drivers would require me to quit my day job. 🙂

I will admit my plan to publish one or two examples that utilize this component in a hardware-based application. I can't promise a delivery date on those, as they get prioritized against lots of other tasks, but the first such example should be up "soon".

David

Re: I2C Digital Waveform (IDW)

David S. — Thu, 12 Feb 2009 23:04:26 GMT

Hi all -

An update to IDW has been released and can be downloaded on the main page. Changes (bug fixes and new features) in v1.1.0 are listed in the readme file.

Re: I2C Digital Waveform (IDW)

Anne_Z — Wed, 11 Mar 2009 22:12:49 GMT

I adjust timing parameters tSU;DAT and tHD;DAT to find the minimum required values by device. But when the parameters are set below 100 nS, output waves stop responding to the settings, the setup and hold time are measured 100 nS regardless of the settings.

How can I remove or reduce the 100 nS overhead?

Anne

Re: I2C Digital Waveform (IDW)

David S. — Thu, 12 Mar 2009 14:37:29 GMT

Hi Anne -

What's your device's sample rate? And what are your desired timing settings?

Can you post the code that doesn't work?

Re: I2C Digital Waveform (IDW)

Anne_Z — Thu, 12 Mar 2009 16:16:04 GMT

Thanks, David.

The attachment is a simplfied version of the current program.

Vih - controls bus voltage using NI-4130 or an external power supply. Vil is set by NI-6552.

I2C clock - sets CLK frequency. Default value is 400K.

Timing parameters are listed at the bottom of front panel.

I edited Mode Timing.dat so the program can pass timing validation.

Anne

Re: I2C Digital Waveform (IDW)

David S. — Thu, 12 Mar 2009 16:58:31 GMT

Hi Anne -

Looking at the default values in your controls and indicators, and at this snippet of code that configures the sample rate fo your HSDIO device:

I suspect that it's getting configured to a rate of 10 MHz or less. On a 10 MHz sample clock, waveform samples are spaced 100 ns apart. This limits the edge placement resolution to multiples of 100 ns. To increase the resolution, you have to increase the sampling rate. (20 MHz ---> 50 ns, 50 MHz --> 25 ns, 100 MHz, 10 ns)

Remember that the 655x uses divide-down sampling of a 200 MHz onboard oscillator to generate the sample clock. This means that not all configured rates are actually achievable. For example, if you try to configure the board to run at 10.2 MHz, it'll coerce the rate to 10 MHz (200/20). To find out what the actual rate is -- and, if you want, change your selection dynamically based on that information -- query the Timing >> Sample Clock >> Rate property from the HSDIO session.

-------------------------

Something else I noticed, too: You wrote an algorithm that appends samples to the I2C waveform in order to coerce its length to a multiple of 2 for the HSDIO board. This functionality is already present in v1.1.0 of the IDW. Just wire a value of "2" into the Sample quantum input on the IDW:Close VI.

Message Edited by David S. on 03-12-2009 11:58 AM

Re: I2C Digital Waveform (IDW)

Anne_Z — Thu, 12 Mar 2009 22:36:44 GMT

David,

Your suggestion of resetting sample rate worked. I am very pleased, though realize that I won't be able to set a near 0 nS setup time. Current sample clock is 98.5M hz. The minimum displayed setup time is 10nS.

I downloaded the IDW 1.1.0. Is "Dig Waveform to Prepend" in Close.vi the same terminal you call Sample quantum?

Thank you very much!

Anne