I2C Digital Waveform (IDW)

[fr@nk]

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?

[David S.]

Hi Frank -

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

1. 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.
2. 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.

[fr@nk]

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 

[David S.]

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

[David S.]

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.

[Anne_Z]

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

[David S.]

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?

[Anne_Z]

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

[David S.]

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

[Anne_Z]

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