mulitple port task diposing for 6537 board

[ToddW]

I keep getting an access viloation exception was unhandled error when trying to creat a digital write channel afte disposing of another channel.  I am using a PCIe-6537 board using DAQmx 8.7.1 with VB.NET 2008.  I am basically trying to create a I2C master using this I/O card.

[Aaron_W.]

ToddW,

Thanks for posting on the NI Forums. I am not sure exactly why you would see this access violation error on your program, but before you go into too much trouble to develop your program I am not sure that you will be able to implement this I2C master design with your PCIe-6537. What speed of I2C are you wanting to operate at? I know there are various speeds. 

We do have some I2C examples, but they all use our 655X series of board, because they support per-cycle tri-state of the lines. If you could give me some more information as to your program that would be helpful. Thanks!

[memoryleak]

This doesn't address your VB.NET issue, as I have about as much experience with VB.NET as I have with I2C (which is exactly 0x00).

Assuming you get that worked out, you're going to have a problem as Aaron pointed out as I2C seems to need the ability to change directions on the fly.

1) If all you need is easy I2C, the USB-8451 can do just that!

2) If you need a DIO device as well, the 655x series that Aaron mentioned has the ability to change individual pins from input to output on the fly

3) If you're married to the 6537 for other reasons (and lets face it, it's a pretty sweet card) you may be able to interface with I2C through a bridge chip that communicates over a bus that's more friendly to the 6537's capabilities (for instance, SPI doesn't require you to change directions).  A quick google turned up the NXP SC18IS600 which has an eval kit that sells for about $50 on Digikey.

Note that option #3 isn't anywhere near as clean/robust (random wires an external PCBs tend to make designs look unprofessional) as #1 and #2, but I assume you chose the 6537 for a reason so you might appreciate a way to let you use the same hardware.

Personally, if the capabilities of the USB-8451 (250khz?) were within my requirements, it would sure be easy to run it along side a 6537, letting the 8451 handle the low speed I2C and the 6537 handle the rest of the muscle.

Hugs,

memoryleak 

[ToddW]

Well the good news is i figured out what was going on with the error.  The bad news is my I2C routine is going way slow on this card.  Some of the previous I2C masters we have created us a 6503 and 6533 cards and are running at 100kHz.  I'm looking to get in the 20kHz range.    As of right now it takes me a long time to generate a clock signal.  i'm using the following code:

Private Sub cmdtest_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles cmdtest.Click

 Dim myTask1 = New Task

Dim myWriter1 As New DigitalSingleChannelWriter(myTask1.Stream)

 

myTask1.DOChannels.CreateChannel(Port, "", ChannelLineGrouping.OneChannelForAllLines)

Dim HIGH(0) As Boolean

Dim LOW(0) As Boolean

HIGH(0) = True

LOW(0) = False

 For i = 0 To 100

myWriter1.WriteSingleSampleMultiLine(True, HIGH)myWriter1.WriteSingleSampleMultiLine(

True, LOW)

Next i

End Sub

Is there anyway to just do a get bit set bit type of routine.  I'm just using some of the standard Digital I/O ports that i though were reconfigurable.  Any ideas would be greately appreciative.

[Aaron_W.]

Todd,

It appears to me as though you are doing software timing with your code and only writing bit by bit instead of loading a waveform on the card and then generating that waveform all at once.  I know you have an email Service Request open with Jim and he and I have been talking about some potential suggestions for you to get you generating a clock signal. He will be sending some of these suggestions in an email and it will just include writing a waveform to the memory of the card and then generating that signal all at once instead of writing single points. Thanks!

[ToddW]

Aaron,

That was one fo the approaches I was looking into.  I do have some questions, about generating a waveform to the memeory of the card, a lot of the I2C protocal calls for a start pulse, which is setting two pins SCL, and SDA high and then low also for the acknowledge the clock ("SCL") is held high while the data pin ("SDA") is configured to read.  Will all this be possible with writing a waveform to memory and generating that signal.

Thanks for the help,

Todd 

[Aaron_W.]

Todd W.

This will all depend on the rate at which you need to change these pins around. The reason why we suggest using the 655X series is because they support  the per-cycle-tristate which will allow you to change individual pins from read to write from one clock cycle to the next. In my experience the only way we have been able to successfully implement the I2C communication is with the 655X series. I have attached a document that talks about our I2C Reference Library. There is also a forum that is linked on the page that talks about the I2C library. I was looking through the forum and found where some of our developers talked about the possibility of using the 653X series, they said the following: 

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. 

I hope this gives you some insight into what you will be limited by. Thanks!

I2C Digital Waveform Reference Library

I2C Digital Waveform Forum

[ToddW]

Aaron W.

Thanks for the suggestions.  We do currently have I2C masters on a PCI-6533 and on a PCI-6503 using a bit-bang method using the traditional DAQ driver with CVI.  The code is really simple and bullet proof.  The issue I seem to be having is when i port it over to the PCIe-6537 board the bit-high to bit-low is rather slow.  using the 6533 and 6503 boards we are getting anywhere from 20kHz to 100kHz on some old P4 machines running 512MB of RAM.  I'm currently looking at some implementation that was done in labview on the forums here: http://zone.ni.com/devzone/cda/epd/p/id/6200#h42

which I hope with what Jim is research will be able to generate a state change that is more efficient.

ToddW.