I2C Digital Waveform (IDW)

[Anne_Z]

David,

 

I noticed the last element fSCL in Validate Timing.vi is compared as if this is the minimum number. Also the message for failed validation lists fSCL as tLOW. Can you verify those?

 

Another question is about rise time.

At SCL=400K and sample rate=100Mhz, SCL’s rise time is greater than 100nS without device (see attachment). 6552 can generate waveforms with much smaller rise time when not combined with IDW library. Is there a way to reduce SCL rise time?

 

Thanks,

Anne

[David S.]

Hi Anne -

I noticed the last element fSCL in Validate Timing.vi is compared as if this is the minimum number.

You're correct; it's a bug. Just swap the wires on that "less than" block to fix it.

Also the message for failed validation lists fSCL as tLOW.

That's incorrect. The message inside "Init.vi" reads as it should. It's checking to make sure there's enough time between falling and rising edges to be able to hold out the previous data value before setting up the next value. Thus, tLOW must be greater than or equal to tSU;DAT + tHD;DAT. Since tLOW is calculated using tHIGH and fSCL, those parameters can be adjusted to fix this issue.

Another question is about rise time.

I2C is an open-drain bus. It relies on an external pull-up circuit for a 0-to-1 transition. The IDW waveform tells your HSDIO device to drive a '0' onto the bus or tri-state the driver for a '1'. It does not command an actively-driven '1'. So the rise time of the circuit is not a function of the HSDIO device's configuration or of the IDW waveform; it's a function of (1) the total line capacitance and (2) whatever pullup mechanism exists on your I2C bus implementation. (This is often a current driver for Fast-mode and High-speed mode buses, as described in the I2C specification.)

[Anne_Z]

David,

Your reply is very helpful.

Regarding the I2C timing violation message, when fSCL is over maximum limit defined in Mode Timing.dat, the message listed it as a tLOW violation as shown in the attachment.

Anne

[David S.]

Oops! 🙂

I'll add that to the bug list for the next version. Thank you.

[Anne_Z]

David,

I am working on I2C command in high speed mode. It requires 1st byte in Fast mode speed (<400Khz) and changing to High speed (<3.4Mhz) for the remaining bytes until a Stop.

I tried using two Init.vi in front of 1st and 2nd byte, but timing information for the 1st byte was not included in the output, and all bytes were set to 3.4Mhz.

How can I change SCL in the middle? 

Thanks,

Anne

[David S.]

Hi Anne -

Although the I2C spec says that "with the exception that arbitration and clock synchronization is not performed during the Hs-mode transfer, the same serial bus protocol and data format is maintained as with the F/S-mode system", I didn't design IDW to work with Hs-mode devices. This is because that mode hasn't been validated on the NI 655x. There are several phsyical-layer requirements that lend me to believe it may not be feasible to use the 655x on Hs-mode bus. From section 5.3.1 of the spec (Rev. 03):

Hs-mode master devices have an open-drain output buffer for the SDAH signal and a combination of an open-drain pul-down and acurrent-source pull-up circuit on the SCLH output. This current-source circuit shortens the rise time of the SCLH signal...the current-source of one master is enabled...only during Hs-mode.

...

The inputs of Hs-mode devices incorporate spike suppression and a Schmitt trigger at the SDAH and SCLHinputs.

...

The output buffers of Hs-mode devices incorporate slope control of the falling edges of the SDAH and SCLH signals.

None of this circuitry is designed into the 655x pin electronics, and so I can't safely say that the 655x is suited to control an Hs-mode I2C bus without some kind of external interface at the end of the cable.

To more directly answer your question, you should view the IDW session as an object in the OOP sense. The Init VI is your constructor function, and each time it's called it creates a new "object" that will ultimately yield a digital waveform when destroyed. Therefore, Init is only to be used once per I2C waveform, for the purpose of creating that waveform. You can use the "Digital waveform to prepend" input of the Close VI to concatenate two waveforms together; I would create an Fm waveform and an Hs-mode waveform, then wire the waveform (output from its session's Close VI) into the Close VI of the Hs-mode session. Here's an idea of what I'm talking about, though this is not necessarily the exact code you should use. I'm not familiar with Hs-mode addressing or data structure; you may have to use the low-level VIs to build your own custom Hs-mode functions. You may also have to edit your copy of IDW to support Hs-mode data structuring.

 

[Sathish]

Hi David,

We areusing NI 6551 and NI6552. I am trying to implement I2C. We don't use Labview and use only C/C++ interface drivers from NI . I downloaded IDW library and it looks like it supports only Labview. Is there a version of API which can be used from Labwindows CVI /C++ environment.

Thanks

Sathish

[David S.]

Hi Satish -

IDW, SDW, and JDW are only available for LabVIEW.

[Sathish]

Hi David,

Thanks for your reply. It is very disappointing that it is not available for Labwindows CVI interface. 

Can u provide me any tutorial or any source where I can refer for implementing I2C protocol with NI 655X board. Any guidance in this sort would be helpful.

thanks and regards

Sathish

[David S.]

Hi Satish -

The only materials I can offer are those used to describe the coding methodology in LV:

- I2C specification

- Serial Protocol Communication for Digital Waveform Devices

- the code comments and documentation inside the IDW VIs

Note that many of the design decisions are based around how LV handles automatic memory copies. The implementation method in C may be drastically different, since you can use pointers and in-place operations in that language.