[CR] MPSSE.dll LABview driver

[Benoit]

Name: MPSSE.dll LABview driver

Submitter: Benoit

Submitted: 10 Feb 2016

Category: *Uncertified*

LabVIEW Version: 2011

License Type: BSD (Most common)

There it is... finaly... 

Because the code given in the FTDI web page is not convenient, not working and haven't been developed by real LABview programmer, I decided to create a library for the I2C.

 

a version for SPI will come soon.

 

This library is free to use. If FTDI want's it in ther site, I do not allow you to publish it since you didn't help any of your customer with LABview.

but of course feel free to publish this link.

Click here to download this file

[ShaunR]

As a "real" LabVIEW programmer Maybe consider distribution via the LabVIEW Driver Network?

[RomainP]

Hello Benoit.

 

Thank you for your library ! But I have done few modifications to be able to use it :

 

I2C Device Read.vi :

- cluster "options" changed ("Acknowledge bit" renamed "Not Acknowledge bit", "Not Acknowledge bit" and "Reserved bit" inverted)

- conversion from and to string for "Data" deleted => Be able to receive also bytes with a value of 0.

MPSSE I2C.zip

[RomainP]

MPSSE SPI done !  https://lavag.org/files/file/291-mpsse-spi/

[Michael78]

Hi, thank you both for posting these libraries.  I was going to have a look but I have a very strange problem.  I can open the project  but if I try to open test.vi (or some other VI's but not all) , LabVIEW hangs for a few seconds, then crashes.  I have installed the d2xxx driver just in case, and I have re-started my PC.  This happens in LV2013 and 2015.  I guess it is something to do with the dll call, but what could it be?  I have not seen this behavior before.  T Hank you for any suggestions you may have,

Michael.

[Benoit]

Sorry for the late reply.

You have to connect at least once your FTDI device and having the driver installed in windows. Then this problem should never happen again.

Benoit

[venustas08]

Hi Benoit,

I have a question.... The MPSSE I2C driver works great. But it does not have a Write-Read dll in it.

Calling the WriteDevice and Read Device separately in LabVIEW is generating considerable delay ( ~1ms windows scheduler + labview ).

is there a combined DLL for Write-Read.

currently I am able to reach only about 400 samples per second with my ADC. I want to be able to use upto 10ksps.

Is there any other way to reduce this delay ? 

Thanks for the help.

 

 

[Benoit]

Sorry for the late reply.

I didn't try to benchmark this library. so performance point of view, I have no idea.

[ShockHouse]

On ‎2‎/‎6‎/‎2017 at 2:51 PM, Michael78 said:

Hi, thank you both for posting these libraries.  I was going to have a look but I have a very strange problem.  I can open the project  but if I try to open test.vi (or some other VI's but not all) , LabVIEW hangs for a few seconds, then crashes.  I have installed the d2xxx driver just in case, and I have re-started my PC.  This happens in LV2013 and 2015.  I guess it is something to do with the dll call, but what could it be?  I have not seen this behavior before.  T Hank you for any suggestions you may have,

Michael.

If anyone else comes across this issue and does not have access to the cables to install the driver (yet) I found a solution.

The issue is the .dll call to libMPSSE.dll (which then tries to access ftd2xx.dll). There are two options to solve this that have worked for me.

A: Although you can't open the individual .vi's, you can open the .lvlib and .lvproj. Open up the .lvllib and delete the libMPSSE.dll that is listed. (Also delete it from the Folder in your OS, save it to a different folder for the time being), This should allow you to open up the .vi's because they can no longer find the .dll so they will not crash. Now you can look at the .vi's for the time being.

B: Another way is to just add the file ftd2xxx.dll to either your SysWOW64 folder or System32 folder (in C:\Windows). Since libMPSSE.dll looks for ftd2xxx.dll it will now find it.

C: Wait for the cable to arrive.

Edited April 5, 2018 by ShockHouse

[Benoit]

Indeed, if you never connect the cable, it will crash.

I have now move away from ftdi. I found a much better solution.

Microchip MCP2221A Also a version for SPI is available.

Amazing IC with a lot more capability for a fraction of the price. We develop our own PCB to interface it and it still become cheaper that the cable from FTDI.

[saran]

can please share the I2C drivers for  Microchip MCP2221A 

 

[Benoit]

It's coming very soon.

I am completing the integration phase this week, therefore it will be tested.

Only the SPI version not validated, but it should work.

Give me one more week.

[ShockHouse]

Just curious if any of you ran across this issue during your time using the FTDI I2C libMPSSE.dll.

I can successfully write to a chip all the time. I can read from a chip a lot of the time, but I run into an issue in one scenario. If I read 6 bytes of value it will return something like this: 0xC08610E07EC0. The problem comes when one of the bytes of data read is 0x00. For instance: If I was to read and wanted to get 0xC08600E07EC0 it would only return 0xC086. This is because that byte right after is 0x00. I know the entire data is being passed back on the SDA line because I checked with an oscilloscope. The problem is just that the buffer for the Call Library Function doesn't return the data. I'm wondering if you guys have seen this issue? If not I'll just start looking into their dll and see what is going on.

[ShaunR]

I haven't looked but it sounds like a c string issue. Rather than returning an array of bytes, a c string type is used to get the data into LabVIEW. Often people prefer the c string because it only requires one call forgetting it can't be used on binary data, whereas to get an array of bytes you usually have to call the function first with a NULL array of length 0 to get the length then call it again with an array of the right dimension size (if there is no dedicated function for that purpose).

Edited June 7, 2018 by ShaunR

[ShockHouse]

41 minutes ago, ShaunR said:

I haven't looked but it sounds like a c string issue. Rather than returning an array of bytes, a c string type is used to get the data into LabVIEW. Often people prefer the c string because it only requires one call forgetting it can't be used on binary data, whereas to get an array of bytes you usually have to call the function first with a NULL array of length 0 to get the length then call it again with an array of the right dimension size (if there is no dedicated function for that purpose).

Your exactly right. I went into the call library function for the read and changed it to a byte array. It now returns the correct values each time. So if anyone uses this and comes across the issue above go into the call library function for the Read and change the buffer to reflect the picture below.

Edited June 7, 2018 by ShockHouse
clarifying

[ShaunR]

Well. It's probably a bit more than that. How do you know how big of an array to pass? If data overwrites the end of the array it will crash LabVIEW.

[ShockHouse]

4 hours ago, ShaunR said:

Well. It's probably a bit more than that. How do you know how big of an array to pass? If data overwrites the end of the array it will crash LabVIEW.

Sorry I should have specified above. The code you download already is initializing an array of the correct size (because it's based on how many bytes you want to read). All you have to do is remove the Byte Array to String that goes into the buffer. And just pass the initialized array straight in to the buffer. So if you take the parameters I posted above, and modify the code to look like below it will work.

Edited June 7, 2018 by ShockHouse

[ShaunR]

30 minutes ago, ShockHouse said:

Sorry I should have specified above. The code you download already is initializing an array of the correct size (because it's based on how many bytes you want to read). All you have to do is remove the Byte Array to String that goes into the buffer. And just pass the initialized array straight in to the buffer. So if you take the parameters I posted above, and modify the code to look like below it will work.

OK. That's fair enough. One thing to be aware of are functions that you can request, say, 1024 bytes but they can return less. In that scenario the length is often written to with the actual bytes transferred. Then that "actual" value should be used with a resize array on the data read. With those types of functions it is also a common error to choose "value" instead of "pointer to value" for the length since 99.9% of the time it seems to work fine with "value"....until LabVIEW crashes 7 hours into a test

[Rolf Kalbermatter]

On 6/7/2018 at 6:59 PM, ShockHouse said:

Your exactly right. I went into the call library function for the read and changed it to a byte array. It now returns the correct values each time. So if anyone uses this and comes across the issue above go into the call library function for the Read and change the buffer to reflect the picture below.

RomainP already mentioned that change in his post here:

- conversion from and to string for "Data" deleted => Be able to receive also bytes with a value of 0.

 

Another useful change not mentioned elsewhere would be to change all the Call Library Nodes to use a Pointer Sized Unsigned Integer variable for the handle parameter and change the controls on the VI frontpanel for the handle to be a 64-bit Unsigned Integer, in order to make the library more future proof to also work with the 64-bit version of the DLL.

Edited January 6, 2020 by Rolf Kalbermatter

[Rolf Kalbermatter]

On 12/14/2017 at 7:28 PM, venustas08 said:

Hi Benoit,

I have a question.... The MPSSE I2C driver works great. But it does not have a Write-Read dll in it.

Calling the WriteDevice and Read Device separately in LabVIEW is generating considerable delay ( ~1ms windows scheduler + labview ).

is there a combined DLL for Write-Read.

currently I am able to reach only about 400 samples per second with my ADC. I want to be able to use upto 10ksps.

Is there any other way to reduce this delay ? 

This is a bit late for you but for others here is some info.

While that DLL does have a ReadWrite function for SPI operation it has no such function for the I2C part of the functions.

One thing you could try is to change the threading of the Call Library Node for the Read and Write function to be run in any thread. This should save some time in invoking the function as no thread switch has to be performed and the execution for of the DLL function has not to arbitrate for the CPU with other UI related things in LabVIEW.

While the documentation does not state that it is safe to call these functions from different threads it could be sort of inferred from the fact that it does state for the functions GetNumChannels() and GetChannelInfo() that it is not safe to do that, while this note is missing for the Read and Write functions. Of course it is very likely not a good idea to let LabVIEW run the Read and Write in parallel on the same communication handle as it is not only not clear which one would execute first but also might mess up the management information stored inside the handle itself if those two functions are executing simultaneously. So make sure there is proper data dependency between the Read and Write function (usually through error wire) to avoid that problem. It's questionable that you will get guaranteed 10kS data transfer with this but you should be considerably faster than with the current VI setup.

Personally if I had to use this in a real project I would most likely implement the I2C and SPI operation entirely in LabVIEW directly on top of the FTD2xx library.

Edited January 6, 2020 by Rolf Kalbermatter

[LittleJoe]

The zip download doesn't work.

[Rolf Kalbermatter]

41 minutes ago, LittleJoe said:

The zip download doesn't work.

It does for me.

[Tomasz]

I think that in toy test app there's an error in wiring between get info and open CH, correct should be:

[QWERT]

We use the MPSSE.dll LABview driver from Benoit.

We are trying the i2c read 1 byte and multi bytes. We expect ack for all bytes except the last byte with nak. During read, we understand that the I2C master drives the ack/nak. However, ack and nak happens randomly.

Any body have any suggestions

Thank you

Dan

[JeremyP]

On 1/6/2020 at 7:02 AM, Rolf Kalbermatter said:

RomainP already mentioned that change in his post here:

- conversion from and to string for "Data" deleted => Be able to receive also bytes with a value of 0.

 

Another useful change not mentioned elsewhere would be to change all the Call Library Nodes to use a Pointer Sized Unsigned Integer variable for the handle parameter and change the controls on the VI frontpanel for the handle to be a 64-bit Unsigned Integer, in order to make the library more future proof to also work with the 64-bit version of the DLL.

Thanks to point it out! It fixed my problem with 64-bit LabVIEW.