Jump to content
Benoit

[CR] MPSSE.dll LABview driver

Recommended Posts

index.php?app=downloads&module=display&section=screenshot&id=282

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

 

4.png

6_b.png

6.png

5b.png

5a.png

Share this post


Link to post
Share on other sites

Sorry for the late reply.

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

Share this post


Link to post
Share on other sites
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 by ShockHouse

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by ShaunR

Share this post


Link to post
Share on other sites
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.

Capture.PNG

Edited by ShockHouse
clarifying

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Capture.PNG

Edited by ShockHouse

Share this post


Link to post
Share on other sites
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.

Capture.PNG

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 ;)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.