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 ... 45 46 [47] 48 49 ... 60
691
Discussion - Software / Re: EVE down signal: sensing continuous
« on: March 20, 2019, 12:53:39 PM »
Hello,

You can check for a pen down condition where the REG_TOUCH_SCREEN_XY becomes not-equal-to 0x80008000 and likewise a pen-up condition where it changes from a coordinate to value 0x80008000. You can use a small state machine or if-else routine in your code to track the previous and current values and therefore detect pen-down and pen-up conditions.   You can use these along with a counter in your MCU code to detect the length of touch that was held on the screen.

As the item is normally a tagged object, you can monitor the tag value and count the number of polls of the tag register where the tag remains at the value of the object being monitored. This can be used to determine how long the touch was held for.

You can also combine these two techniques to allow you to detect both how long a touch is held and for how long it was on the particular tagged item being monitored. e.g. if you detect pen-down, also poll the TOUCH_TAG register to confirm that the touch is actually on the image button whilst waiting for the pen-up.

If you use interrupts, there are also interrupts available for both touch detect and the tag value changing which could be used to reduce the polling required in the above cases.

Best Regards,
FTDI Community

 




692
Discussion - Hardware / Re: txe and rxe signals in FT232H
« on: March 19, 2019, 08:59:38 AM »
Hello,

Do you mean RXF# and TXE#?

RXF#:
When high, do not read data from the FIFO. When low, there is data available in the FIFO which can be read by driving RD# low. When in synchronous mode, data is transferred on every clock that RXF# and RD# are both low. Note that the OE# pin must be driven low at least 1 clock period before asserting RD# low.

TXE#:
When high, do not write data into the FIFO. When low, data can be written into the FIFO by driving WR# low. When in synchronous mode, data is transferred on every clock that TXE# and WR# are both low.

A write operation can be started when TXE# is low.

A read operation is started when the chip drives RXF# low.

Best Regards,
FTDI Community

693
Discussion - Software / Re: Partial screen update with FT813
« on: March 18, 2019, 01:31:27 PM »
Hello,

Please have a look at the following Application Note:
https://brtchip.com/wp-content/uploads/Support/Documentation/Application_Notes/ICs/EVE/AN_340_FT800_Optimising-screen-updates-with-Macro-and-Append.pdf

The methods described in this should be helpful for you.

Best Regards,
FTDI Community

694
Hello,

I would suggest that if you are not using touch controls that it would be fine to add a Sleep to the main loop.
Adjusting for your desired refresh rate would be acceptable.

Best Regards,

FTDI Community

695
Discussion - Hardware / Re: Cannot flash EEPROM FT232RL
« on: March 11, 2019, 10:49:50 AM »
Hello,

This is a 3rd party product.  Since this is not one of our products, although it may utilise our device, it is difficult to offer any support on it as FTDI cannot control how the USB ICs are used and has no knowledge of the entire product.

Product Manufacturers are responsible for supporting end-users of their products, so you will need to contact the manufacturer directly. 

Please see the following document for reference:

http://www.ftdichip.com/Support/Documents/TechnicalNotes/TN_102_OEM_Technical_Support_Requirements_for_FTDI_Products.pdf

Regards,
FTDI Community

696
Discussion - Software / Re: ftd2xx.lib
« on: March 07, 2019, 02:12:48 PM »
Hello,

The ftd2xx.lib is COFF.

I believe COFF2OMF.exe is part of RAD Studios so you may want to contact them about this, or perhaps someone on the forum has some experience with using the tool.

Regards,
FTDI Community

697
Discussion - Hardware / Re: Cannot flash EEPROM FT232RL
« on: March 06, 2019, 04:46:36 PM »
Hello,

After programming in FT_Prog did you hit the Cycle Port button?

If you are still having problems can you confirm which of our devices that you are using please? i.e a cable or a development module?

Regards,
FTDI Community


698
Discussion - Drivers / Re: Ft201X & ftd2xx.dll
« on: February 20, 2019, 02:18:32 PM »
Hello,

You could try changing the latency timer (FT_SetLatencyTimer) to 1 or enabling flow control in your application program (FT_SetFlowControl). Have a look at the D2XX Programmer Guide for further details:

https://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf

Regards,
FTDI Community.

699
Discussion - Software / Re: Different writing speeds
« on: February 05, 2019, 04:38:34 PM »
Hello,

Please try with our beta version of LibMPSSE which can be downloaded here:

libMPSSE__0_6_Beta.zip

You may also want to try without the LibMPSSE library and use the D2XX drivers direct. This gives a little more control. Some examples exist here:

https://www.ftdichip.com/Support/SoftwareExamples/MPSSE.htm#SPI

However, this is most likely due to the nature of USB. If there is more USB traffic then the OS and USB have to schedule the communication with each of the USB devices.
It’s highly dependent on the OS and USB Host and is out with our control.
FT2232H use USB Bulk transfers and those are designed to transfer large amounts of data with error-free delivery, but with no guarantee of bandwidth.

Best Regards,
FTDI Community

700
Hello,

Can you ensure that you are using the latest version of our FTD3XX driver, which you can obtain here:

FTD3XX_NET.ZIP

If you are still having problems after trying this please can you contact email support on support1@ftdichip.com, referencing this thread and we will assist you further.

Regards,
FTDI Community

701
Discussion - Hardware / Re: continuous clock?
« on: February 05, 2019, 11:21:32 AM »
Hello,

Unfortunately it would not be possible to produce a continuous Clock signal using MPSSE commands. At some point the MPSSE commands would be split across a USB packet, the timing of USB packets is not deterministic and this will result in a pause with your Clock signal. The MPSSE functionality was designed as a clocking engine for data and not to run continuously.


Best Regards,
FTDI Community 

702
Hi,

It will be no problem to use several FT2232H on the same PC at the same time.

The location ID would allow you to check the actual location (with respect to the USB device tree) as you mentioned. 

However, since FT2232H are all identical (no internal EEPROM) then there is no way for the driver to identify a particular FT2232H unless they are always plugged into exactly the same ports on the PC. We recommend fitting the EEPROM so that you can identify each FT2232H as well as telling which ports are on the same FT2232H.

Best Regards,
FTDI Community

703
Hi,

We normally recommend to fit the EEPROM and to program it with a string which represents the purpose of the device e.g. "Datalogging Interface" and "Programming Interface". This allows you to easily identify which chip you are opening as well as the port. Other methods relying on location ID or index could have dependency on which physical port the user plugs each chip into and which order they are connected in.

Opening by the description appended with an A or B for the respective port would allow you to easily find and open the correct port without any manual selection by the user.
ftStatus = myFtdiDevice.OpenByDescription("Datalogging Interface B");

Best Regards, FTDI Community

704
Hello,

If you use multiple channels, ensure to have an instance for each and you can then open and use them as shown below:

Code: [Select]
FTDI myFtdiDeviceCHA = new FTDI();
FTDI myFtdiDeviceCHB = new FTDI();
...
...
ftStatus = myFtdiDeviceCHA.OpenByDescription("FT2232H A");  // assuming EEPROM description is "FT2232H"
ftStatus = myFtdiDeviceCHB.OpenByDescription("FT2232H B");  // assuming EEPROM description is "FT2232H"
...
...
ftStatus = myFtdiDeviceCHA.Write(buffer, NumBytesToSend, ref NumBytesSent);
ftStatus = myFtdiDeviceCHB.Write(buffer, NumBytesToSend, ref NumBytesSent);

Best Regards, FTDI Community









705
Discussion - Drivers / Re: Forcing/pre-set RTS and/or DTR to user levels
« on: January 28, 2019, 09:38:41 AM »
Hello,

Unfortunately these can't be set to particular start-up states in the device itself and so you would need to configure them from the terminal once the port is open. Many terminals have check boxes or menu options for this which can set/clear the lines manually but only once the port is open.

Best Regards, FTDI Community


Pages: 1 ... 45 46 [47] 48 49 ... 60