Activity for Stephen Davies
-
Stephen Davies posted a comment on ticket #13
Hi Peter, the best way to do this is for you to: 1) fork the github project 2) make your changes locally 3) commit your changes to Github 4) send a Github pull request Regards, Stephen
-
Fantastic! Have you got it talking to a device yet?
-
Just checked my setup. Directory C:\Users\me\d2xx contains 4 files - ftd2xx.h, LibFT4222.h, ftd2xx.lib and LibFT4222.lib. The .dll file mentioned in step 4 is not in that directory. That step should be ignored. Directory C:\Windows\System32 contains - ftd2xx.dll, FTDIInterface.dll and LibFT4222-64.dll. Directory C:\Windows\SysWOW64 contains - ftd2xx.dll only. I don't remember touching SysWOW64, suspect that Windows PnP driver installation put the ft2dxx.dll's into both System32 and SysWOW64. Be warned,...
-
I've uploaded the .dll and .jar files that produced that output to: https://sourceforge.net/projects/yad2xx/files/REL-2.1-SNAPSHOT/
-
Hi Peter, I hate to say it but it works for me: C:\Users\usr\projects\yad2xx>java -cp yad2xxJava\target\yad2xxJava-2.1-SNAPSHOT-jar-with-dependencies.jar net.sf.yad2xx.ft4222.samples.I2cMasterSample Dev 0: Flags=2 (isOpen: false isHighSpeed: true) Type=a (FT_DEVICE_4222H_0) ID=403601c locID=121 SerialNumber=A Description=FT4222 A ftHandle=0 Init FT4222 as I2C master I2C master write data to the slave(0x20)... bytes written: 2 I2C master read data from the slave(0x20)... slave data: 0xa5, 0xc3, UnInitialize...
-
Hi Peter, the UMFT4222EV module turned up yesterday. I've got the example code working correctly on macOS with a PCF8575 I2C slave device: yad2xx$ java -cp yad2xxJava/target/yad2xxJava-2.1-SNAPSHOT-jar-with-dependencies.jar net.sf.yad2xx.ft4222.samples.I2cMasterSample Dev 0: Flags=2 (isOpen: false isHighSpeed: true) Type=a (FT_DEVICE_4222H_0) ID=403601c locID=14111 SerialNumber= Description=FT4222 A ftHandle=0 Init FT4222 as I2C master I2C master write data to the slave(0x20)... bytes written: 2...
-
I spent some time working on this over the weekend on macOS. I encountered similar problems with 3rd party libraries. It looks like LibFT4222 has been written in C++ and this means that the driver is not standalone, it requires additional libraries to function. On macOS this means the boost libraries need to be present. FTDI ships the correct versions as part of the LibFt4222 download but because they don't provide any install instructions it's easy to overlook. I hadn't set my environment up correctly,...
-
The associated makefile. Use command "mingw32-make" to build.
-
My C test file
-
ListDevices has stopped working because you've moved to the new dll which depends on ftd2xx .dll and LibFT4222.dll. The old version depends only on ftd2xx.dll. When I was testing my simple C program I first installed the current c++ redistributable from https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads , i.e. the version for 2015,2017,2019. When that didn't fix the error I installed the 2010 redistributable. Maybe you need both?
-
I had one last go at it, writing a simple C code sample, rather than Java. Looks like LibFT4222 depends on an old Microsoft dll that doesn't get installed as part of the regular build, MSCVP100.dll. With the C program I was getting a popup error message, something that is supressed by Java. Try installing the Visual Studio 2010 C++ Redistributable - http://www.microsoft.com/download/details.aspx?id=26999
-
Arrrgh!, thought I had it but no. Forgot I was using the old version of FTDIInterface.dll. Still broken. It's late, I'll look at it again tomorrow.
-
Think I've got it. C:\Users\Peter\d2xx should have the files (amd64): 1. ftd2xx.h 2. ftd2xx.lib 3. LibFT4222.h 4. LibFT4222.lib The .dll files go in C:\Windows\System32. ftd2xx.dll will get installed automatically by windows the first time you install an FTDI device. This is normal PnP (plug and play) behaviour. FTDI have given the driver to Microsoft. You do not need to copy ftd2xx.dll into C:\Windows\System32. For me, note I am testing with an old UM232R module, not an FT4222 based device, I had...
-
Think I've got it. C:\Users\Peter\d2xx should have the files (amd64): 1. ftd2xx.h 2. ftd2xx.lib 3. LibFT4222.h 4. LibFT4222.lib The .dll files go in C:\Windows\System32. ftd2xx.dll will get installed automatically by windows the first time you install an FTDI device. This is normal PnP (plug and play) behaviour. FTDI have given the driver to Microsoft. You do not need to copy ftd2xx.dll into C:\Windows\System32. For me, note I am testing with an old UM232R module, not an FT4222 based devices, I had...
-
Actually, did you try copying LibFT4222.dll to C:\Windows\system32 ?
-
OK, I've run out of ideas. I'm going to build my own Windows 10 environment to try this out. I don't have one readily available so this may take a day to two. Will let you know when I get there.
-
Try "regsvr32 /n /i c:\Users\Peter\d2xx\LibFT4222.dll"
-
Ok, plan B. Try adding c:\Users\Peter\d2xx to your PATH.
-
Which chip are you planning to attach to the I2C bus?
-
All good, making progress. That looks like the FTDIInterface.dll is loading but then failing because it can't find LibFT4222.dll. https://github.com/dotnet/iot/blob/master/src/devices/Ft4222/README.md hints at what needs to be done. You can either: 1. Open a Windows Command Prompt (Run as Administrator) 2. regsvr32 c:\Users\Peter\d2xx\LibFT4222.dll or copy it to a directory on your PATH.
-
The FTDI library install instructions are rubbish on Windows. This seems to make more sense: https://github.com/dotnet/iot/blob/master/src/devices/Ft4222/README.md From LibFt4222.zip: 1. copy imports\ftd2xx\ftd2xx.h c:\Users\Peter\d2xx\ftd2xx.h 2. copy imports\ftd2xx\amd64\ftd2xx.lib c:\Users\Peter\d2xx\ftd2xx.lib 3. copy imports\LibFT4222\inc\LibFT4222.h c:\Users\Peter\d2xx\LibFT4222.h 4. copy imports\LibFT4222\inc\amd64\LibFT4222-64.dll c:\Users\Peter\d2xx\LibFT4222.dll 5. copy imports\LibFT4222\inc\amd64\LibFT4222.lib...
-
Ok, it's not finding the header file. What files have you put in C:\Users\Peter\d2xx? You'll need to have ftd2xx.h, libft4222.h, ftd2xx.lib (64 bit) and LibFt4222.lib (64 bit).
-
https://www.atlassian.com/git/tutorials/syncing/git-pull
-
Forgot to mention, ListDevices looks good. The type is set to 0xA (10) and is being recognised as an FT4222 device. The new getDevices() method is likely to work.
-
Ok, copying the old .dll will always fail. We are adding new native functions that do not exist in the old library. We need to get your build working. Please post an image of the error messages that occur further up the screen. They should be coming out of either the C compiler or the linker. You will also need to perform a "git pull" as I have made additional changes to the source code.
-
I assume that you have been able to build from source. Sounds like it is still using the old dll. Please run net.sf.yad2xx.samples.ListDevices and attach the output. This program dumps all device information. It shows all of the device fields, the type is what's important. It should indicate multiple devices of the FT4222 type. Then run DumpSystemProperties, samples package as well. Run it inside your IDE, not from the command line, so we can see what the IDE settings may be doing. What is java.library.path...
-
Hi Peter, have changed getDevices(). Let me know how it turns out please. I have no FT4222 device, therefore no way to easily test.
-
It's late evening here, will implement it timorrow. You need to download the FT4222 support files from the FTDI website. I've updated the github wiki, added page FT4222 Function Index. You could try implementing one of the general functions, say one of the set functions that takes a boolean arg and returns nothing besides the status code.
-
Excellent progress. What I had in mind for getDevices is for it to return a hetergeneous array of Device and FT4222Device instances. Right now it only returns an array of Devices, so when I2cMasterSample line #91 performs instanceof the test fails. To make getDevices work correctly you will need to add code to (refs to FTDIInterface.c): 1. Also lookup class FT4222Device (lines 354-358) 2. Lookup the constructor for FT4222Device (lines 374-378) 3. Test the device info and conditionally construct either...
-
I2c support for FT4222
-
Peter, I've made a first pass at getting it working, code has been checked in to the lib4222 branch. Have only tested it on macOS so there may be a few hiccups on the windows build. FTDI's i2c_master.cpp program has been implemented as I2cMasterSample. It won't yet work as: 1. native method FTDIInterface.getDevices needs to be changed to return FT4222Device instances 2. I don't have a device to test it with 3. i2cMasterRead and i2cMasterWrite are currently stubbed
-
Have you read through https://github.com/aushacker/yad2xx/wiki/Building-on-Windows yet? I suggest you follow the steps and see how it goes. I haven't tried building on Win 10 but the instructions should be pretty close. Would appreciate any feedback, please create an issue on github for documentation errors. Your contribution to the project is most welcome. I've created branch 'lib4222' in the repo for this development. To get the source tree: 1. Install the git client 2. Change to your working directory/workspace...
-
BTW, the project has moved over to https://github.com/aushacker/yad2xx.
-
Hi Peter, thanks for your interest. I haven't encountered the FT4222 before. Whilst the datasheet explicitly mentions the D2XX driver it gives no indication of the commands that need to be issued. It looks like they put another library, LibFT4222, over the top of the D2XX driver. I had a quick look through the Windows version of the LibFT4222 code samples. None of them use D2XX api calls directly, they use the LibFT4222 api. Did a search but failed to find any source code for LibFT4222. I guess FTDI...
-
mvn compile fails for libFTDInterface
-
A way to make a libFTDIInterface for 64 bit Linux?
-
Closed, works for me.
-
SPI broken output waveforms
-
Closed, nothing heard from FTDI.
-
mvn compile issue on mac with fix
-
Your pull request has been merged. Thanks Robert.
-
Hi, which version of macOS are you running? Today I upgraded to Mojave. I then synched my local git repo with GitHub (was already up to date). I tried running mvn and got a weird error, need to run 'xcode-select --install'. Once that had run ok I executed 'mvn clean install', ran just fine.
-
Hi Robert, I find it strange that we have similar configurations but appear to be getting different results. I'm testing this with a Dangerous Prototypes FT2232H v1.0 breakout board. At this point you might want to ignore Java and try running the FTDI C examples. The problem is in the driver, not the Java layer. Once you get those working we can return to yad2xx. By the way, I have sent a support request to FTDI about the supervisor (sudo) requirement. That doesn't sit well with me. Regards, Ste...
-
Hi Robert, got the ListDevices sample app to run ok today. Steps were: 1) Install D2XX drivers as per the video (on FTDI drivers page) 2) Attach device. Running 'lsmod' should show ftdi_sio and usbserial modules loaded. 'ls /dev' listed ttyUSB0 and ttyUSB1. 3) 'sudo rmmod ftdi_sio' 4) 'sudo rmmod usbserial' 5) 'ls /dev' no longer lists ttyUSB0 and ttyUSB1 6) Run 'sudo java -jar yad2xxJava-x.x-SNAPSHOT-jar-with-dependencies.jar net.sf.yad2xx.samples.ListDevices' The trick was running the JVM with...
-
Hi, got it all working. You'll need anothe git pull, maven clean and rebuild then copy the shared library to the Java library path (https://github.com/aushacker/yad2xx/wiki/Binary-Installation). Let me know how you go.
-
Have updated the page re wget and tar suggestions. Are you using openjdk or the Oracle JVM?
-
Sounds like you missed the bit in AN220 about copying the library (sec 2.1.1). sudo cp /opt/ftdi/v1.4.8/build/libftd2xx.so.1.4.8 /usr/local/lib sudo ln -s /usr/local/lib/libftd2xx.so.1.4.8 /usr/local/lib/libftd2xx.so
-
Hi Robert, set up an Ubuntu workstation and made some progress today. Suggest you read https://github.com/aushacker/yad2xx/wiki/Building-on-Linux first. Let me know what I've left out. You will also want to do a git pull as I've changed the Linux POM.
-
BuildLinux
-
BuildLinux
-
BuildLinux
-
BuildLinux
-
Home
-
Hi Robert, a couple of thoughts. 1) Am no Linux expert but the ttyUSB0/1 thing may be a problem as it suggests the OS has taken ownership of the FTDI device. This could mean that the devices will be unavailable for D2XX api operations. There is a known driver issue on macOS https://sourceforge.net/p/yad2xx/wiki/OS%20X%20Device%20Drivers/ There may be a similar problem on Linux where the default driver only allows the FTDI device to operate as a serial port via the Posix APIs. Check out the FTDI driver...
-
Hi Robert, I've decided to move the project over to Github. Apparently it's where all the cool kids hang out ;) Any chance you could clone https://github.com/aushacker/yad2xx then apply your changes and send me a pull request? Haven't done this before and need the practice.
-
Hi Robert, according to ticket #10 you are now successfully compiling the native library on Linux with JDK 8. Is it safe to say this is less of a bug and more of a feature request? I am currently in discussions with another yad2xx user re the future. My intention has always been to migrate to later JDKs but this will be at the expense of build complexity i.e. I'm not sure the methods used to build yad2xx on JDK 7/8 are compatible with JDKs 9/10 and 11.
-
Hi Robert, try: <packaging>so</packaging> and <artifactid>soFTDIInterface</artifactid>
-
Probably. The javah tool was removed in JDK 10 and replaced by improvements in javac. See https://openjdk.java.net/jeps/313 for details. When JDK 9 was released I looked into ways of using Maven to create a single Java module, incorporating the .jar and both native libraries (.dll and .jnilib) into a single file. Unfortunately I was unable to get it working in the time that I had. Now that Java 11 is here it's probably time to revisit.
-
Hi Robert, welcome back. Adding a Linux port shouldn't be too much work. The Maven project has been set up as multi-module. It always builds the common JAR then depending on the build OS it builds one of the two possible native libraries. See <profiles> in trunk/pom.xml, lines 96-124, for details. </profiles> I'm about to head off on holiday. If you find you have a desperate need for this code I suggest: 1) install the FTDI Linux 64 bit driver 2) alter trunk/pom.xml. Cut & paste one of the existing...
-
Exception "not MPSSE capable" at FT232H
-
Hi Oliver, welcome back. Haven't used libMPSSE as a source for yad2xx, just the application notes. FTDI do make the source code available at their website. I would be curious as to what change they made to fix the clock glitch. It may be that there is an error in the application notes and it got copied by the libMPSSE writers and myself. More advanced FTDI devices have 16* I/O pins per channel (xDBUS and xCBUS). Functions setDataBitsLow/High deal with the low and high order bytes of each channel...
-
Oliver, are you still having driver issues?
-
Reference to AN135.
-
Oliver, you have to improve the way you report issues. It is very difficult to help when you: 1) raise multiple issues within a single ticket 2) use one ticket to refer to a problem in another ticket Regarding the exception - java.lang.IllegalStateException: Unable to synchronise MPSSE Firstly, it has nothing to do with VCP/D2XX driver selection. The get here the D2XX driver is talking ok. At this point the framework has sent a series of initialisation commands to the MPSSE engine (Mpsse.initialise())...
-
My experience with FTDI drivers is that they are more complicated and less documented than I would like, both macOS and Windows. My understanding of the current Windows CDM is that there is a bit in the devices EEPROM that can be set to indicate VCP/D2XX driver preference. The FTProg utility fom FTDI lets you mess with the EEPROM settings. Another issue that used to be a problem (haven't tested this in a while) is that changing the USB port (i.e. moving) would create a new COM port. Under certain...
-
If that's the case then those signals look terrible. I also fail to see why it has anything to do with this project. It seems to be a hardware problem to me. Have you read the device datasheet? I seem to recall something about the FT232H having open drain outputs.
-
Hi Oliver, this is not an issue with yad2xx, it is an FTDI 'feature'. See FTDI's AN232R-04 Windows Combined Driver Model pg 5 for information.
-
SPI broken output waveforms
-
Hi Oliver, the top left corner of the scope trace indicates that you are measuring a 10MHz square wave at 50MS/s. Seems to me the sample rate is too low and what you are seeing is aliasing. Are you able to increase the sample rate? Agree that the chip select doesn't look right. Will investigate further.
-
Ok, seems to me that the VCP driver is being selected, rather the the D2XX driver. Try this: 1) Open the Windows Device Manager 2) Expand Universal Serial Bus Controllers 3) There should be an entry for the FT232H, probably named USB Serial Converter 4) Select the device and open its Properties 5) Open the Advanced tab If the Load VCP box is checked this means the VCP driver has control. Your device is operating as a COM port and is not available to D2XX (or yad2xx). Uncheck the box, then unplug...
-
Also, I would be interested in the output of the ListDevices sample program. Instructions on how to run it can be found under 'First Steps' in https://sourceforge.net/p/yad2xx/wiki/BinaryInstallation/
-
Hi Oliver, agreed, that doesn't sound right. MPSSE capability is hardcoded into the DeviceType class. With an FT232H attached device.getType() should return DeviceType.FT_DEVICE_232H. If you are able to debug, what is returned when device.getType() is called? I suspect it may be DeviceType.FT_DEVICE_UNKNOWN.
-
BuildWindows
-
Home
-
Tag for release 1.0.
-
1.0 Release
-
Update Windows DLL build settings.
-
BuildWindows
-
BuildWindows
-
BuildWindows
-
Maybe error in Device.setBaudrate()
-
Hi Oliver, good to hear that you're up and running. Thanks for the IOStreams code. Will look into incorporating them into the project. Yad2xx is also using JUnit. Regards, Stephen
-
Hi Oliver, 4 days ago your issue was transactReadWrite reporting a problem with FT_Read (FT_IO_ERROR). I suspect this may be caused by the way your code is implemented i.e. using multiple threads. Concurrent use of a single Device is centainly going to end in failure. Is there any chance that this may have occured? Did two (or more) threads try to make concurrent calls to Spi.transactReadWrite? Todays stack trace (private email) reports a call to FT_Write failed with FT_INVALID_HANDLE. The most likely...
-
Hi Oliver, am unable to replicate the first exception. Some more information would be helpful: 1) What is the byte[] length being passed in to transactReadWrite, i.e. the argument to call Spi.java:309? 2) Is this the first time transactReadWrite has been called? 3) Do you have a code sample you can share? Method signature for Spi.transactReadWrite has changed from (byte[]) to (byte...). This allows invocation with a single byte, a comma separated list of bytes or a byte[]. The second exception I...
-
Improvement suggested in ticket #7. Alter Spi.transactReadWrite signature to use varargs.
-
Fix for ticket #7. Initial buffer size in Mpsse is way too small.
-
Refactor Mpsse, moving the hardcoded command values to a separate enum type.
-
Add support for functions FT_SetResetpipeRetryCount, FT_StopInTask, FT_RestartInTask and FT_SetDeadmanTImeout.
-
Function Index
-
SPISample
-
SPISample
-
Minor documentation and code changes.
-
AsyncSerialSample
-
FirstSteps
-
FirstSteps
-
FirstSteps
-
Hi, the framework is written in layers. The Spi layer wraps an Mpsse object which in turn wraps a Device. Mpsse has lots of commands, only a few are SPI specific. If you read through the FTDI application notes and then walk through Spi.open() and its calls into various Mpsse methods you will be able to match up the FTDI code samples with yad2xx. Remember that the Mpsse code is intended to be generic and is shared by the Spi, I2c and Jtag classes.
-
Hi Oliver, comments inline. I have to send >2kB every 10ms. First tests with this task resulting in an exception after a short time, not immediatly. My first idea (and the only which I have investigated) are buffer overflow or some similar. Which method(s) in Spi was(were) being called? What was the stack trace? Spi testing has been limited. It works with basic bytes, DotStar LEDs and serial EEPROMs. It has not been tested in a high bandwidth/high throughtput situation yet. Looking at the code, Spi.writeBits()...
-
Function Index
-
Add support for functions FT_Rescan and FT_Reload.
1 >