FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  

News:

Welcome to the FTDI Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ FTDI Support


New Bridgetek Community is now open

Please note that we have created the Bridgetek Community to discuss all Bridgetek products e.g. EVE, MCU.

Please follow this link and create a new user account to get started.

Bridgetek Community

Show Posts

You can view here all posts made by this member. Note that you can only see posts made in areas to which you currently have access.

Messages - FTDI Community

Pages: 1 ... 56 57 [58] 59 60
856
Discussion - Software / Re: FT232RL and D2XXUnit on Windows7
« on: February 23, 2018, 02:57:28 PM »
Hello,

Could it be that the compiler isn't running correctly on Windows 7?

Unfortunately we do not have extensive Delphi experience, the only examples we have available can be found at the following:
http://www.ftdichip.com/Support/SoftwareExamples/CodeExamples/Delphi.htm

Best Regards,

FTDI Community

857
Test and Review Area / Re: libMPSSE Beta
« on: February 22, 2018, 04:09:30 PM »
Hello,

We have requested this information from the developers.

Best Regards,
FTDI Community

858
Hello,

OK we have not received your email yet, I'll look out for it.

Have you considered adjusting the transfer size to better suit your application using FT_SetUSBParameters?
The default is 4096 bytes but can be adjusted in multiples of 64 bytes between 64 bytes and 64k bytes.
Please see the D2XX Programmer's Guide for more information.

Best Regards,
FTDI Community

859
Discussion - Hardware / Re: FT4222H Slave Losing bytes
« on: February 22, 2018, 02:34:16 PM »
Hello,

Maintaining the data in packets as close to multiples of 62 may be beneficial, however the number of packets required to send 6630 bytes of data and 6634 bytes of data is the same at 107.

The FT4222_GetMaxTRansferSize function returns the maximum packet size in a transaction. Thus keeping your data packets within the value returned would ensure only one USB transaction is required to transfer the whole packet.

It may be worth experimenting with the your data packet size to establish what returns the best result.

Best Regards,

FTDI Community

860
Discussion - Hardware / Re: FT4222H Slave Losing bytes
« on: February 21, 2018, 10:52:16 AM »
Hello,

We recommend that you place a known starting byte at the beginning of each data packet.
There is no guarantee that your data packets will align correctly with USB packets, as the USB host is responsible for scheduling transfers. The best approach would be to try to achieve the greatest throughput possible and sort out the data once in Labview.

Best Regards,

FTDI Community

861
Discussion - Software / Re: FT4222 question from a newbie
« on: February 20, 2018, 03:05:17 PM »
Hi,

Can you take a look at the Examples contained in v1.4.0 of the LibFT4222 Windows Library, available here:

http://www.ftdichip.com/Support/SoftwareExamples/LibFT4222-v1.4.zip

If you are still having problems please contact us on support1@ftdichip.com and we will assist you further.

Best Regards,
FTDI Community

862
Hello,

There are known issues with FIFO in the Linux d2xx driver, unfortunately there are currently no plans to fix these.

However, one of our Linux customers has used a third party FTDI library called LibFTDI to get 40 MByte/sec performance with Sync FIFO with the latest Linux kernels.
It may be worth giving this library a try to see if it resolves your issues.
 
http://www.intra2net.com/en/developer/libftdi/
 
Keep in mind FTDI cannot support this API since it is developed and maintained by a third party.


Best Regards,

FTDI Community

863
Hello,

This does not sound like normal behaviour.

There could be another issue.

Maybe there is a timeout?

Can you try removing the event character from the data stream and only send 62 bytes of data to see how long it takes to be available?

If you want to send an email to support1@ftdichip.com we could investigate this issue further?

Best Regards,
FTDI Community

864
Hello,

If you are sending 62 bytes of data and then the event character, then the event character could be sent in the next packet of data (64 bytes in total with two status bytes). This could violate this rule:

The event character will not work if it is the first character in the buffer.

However you need to decide whether you really need event characters. If you are sending 62bytes of data then it will be send immediately since you are sending a full buffer of data.

Best Regards,
FTDI Community


865
Hello,

If the event character is enabled and it is detected in the data stream, then the contents of the devices buffer is sent immediately. The event character is not stripped out of the data stream by the device or by the drivers, it is up to the application to remove it. Event characters may be turned on and off depending on whether large amounts of random data or small command sequences are to be sent. The event character will not work if it is the first character in the buffer. It needs to be the second or higher. The reason for this being applications that use the Internet for example, will program the event character as '$7E'. All the data is then sent and received in packets that have '$7E' at the start and at the end of the packet. In order to maximise throughput and to avoid a packet with only the starting '$7E' in it, the event character does not trigger on the first position.

You may also want to take a look at the latency timer.

The latency timer is a form of time-out mechanism for the read buffer of FTDI devices. When a FT_Read instruction is sent to the device, data will not be sent back to the host PC until the requested number of bytes has been read. If the requested number of bytes never comes, the device would not send data back.

The latency timer counts from the last time data was sent back to the PC. If the latency timer expires, the device will send what data it has available to the PC regardless of how many bytes it is waiting on. The latency timer will then reset and begin counting again.

The default value for the latency timer is 16ms. This value may be customised by adding or changing the following entries in the FTDIPORT.INF file of the driver before installation.

[FtdiPort232.NT.HW.AddReg] 
 
HKR,,"LatencyTimer",0x00010001,50 
 
This example will set the default latency timer value to 50ms. The valid range for the latency timer is 1ms - 255ms, although 1ms is not recommended as this is the same as the USB frame length.

The latency timer value is held in the registry under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\FTDIBUS\{Device VID, PID and serial number}\0000\Device Parameters\LatencyTimer 
 
Please see AN232B-04 Data Throughput, Latency and Handshaking for additional information on the latency timer.

Best Regards,
FTDI Community

866
Discussion - Software / Re: VDrive2 and VDrive3
« on: February 15, 2018, 11:53:36 AM »
Hello,

We have an example of using the LFAT driver with VNC2, this would allow longer filenames with the VDrive3.

Please see the following:
http://www.ftdichip.com/Support/Documents/AppNotes/AN_189_Vinculum-II_Using_the_LFAT_Driver.pdf

Here is a download link to the LFN archive for v1.4.4:
ftp://ftp.ftdichip.com/CES/LFN.RAR

To integrate the LFAT library with the IDE,  copy the files in the folders:
 
Copy the LFAT.a to the C:\ProgramData\FTDI\Vinculum II Toolchain\Firmware\Drivers\lib folder.
Copy the LFAT.h to the C:\ProgramData\FTDI\Vinculum II Toolchain\Firmware\Drivers\include folder.

Note this is not the ‘Program Files’ area where similar folders exist:
C:\Program Files (x86)\FTDI\Vinculum II Toolchain\Firmware\Drivers\include
 
The sample application, V2DAPLFN, is provided as an example of the use of the LFAT library.


Best Regards,

FTDI Community

867
Hello,

Thanks for your feedback, please let us know if you have any more questions.

Best Regards,

FTDI Community

868
Hi,

Thanks for your question. If you email support directly on support1@ftdichip.com they can take a look more closely at your question and get back to you.

Thanks,
FTDI Community

869
Hello,

Thanks for your question.

There are known issues with Windows 7 and USB 3.0 ports, explained in the following document:
http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_152_USB_3.0_Compatibility_Issues_Explained.pdf

It is possible that this could be causing the devices to show up with the same COM port number, are you using USB 3.0 ports?

Another possibility is if the devices have the same serial number, you can check and change the serial number using our FT_Prog utility:
http://www.ftdichip.com/Support/Utilities.htm#FT_PROG

Best Regards,

FTDI Community

870
Discussion - Software / Re: libft4222 error
« on: January 29, 2018, 04:44:08 PM »
Hello,

Would it be possible for you to email your question with an example of your code to support1@ftdichip.com?
Could you also include which revision of the IC you are currently using.

Best Regards,

FTDI Community

Pages: 1 ... 56 57 [58] 59 60