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

Pages: [1] 2 3 ... 10
 1 
 on: February 22, 2019, 12:53:16 PM 
Started by Pereubu123 - Last Post by Pereubu123
Maybe I tried to explain the problem in rather confusing way. I will try again:

Let assume that memory device work in mode 0 or mode 3. let us decide to use mode 0.
Where CPOL = 0, CPHA = 0, mode 0.
For this mode, input data is latched in on the rising edge of serial clock (C), and
output data is available from the falling edge of C.
So when we let say  my program is used to read one word data from a random address:
one write command plus address is used  and then on the side mpsse we should use on the
raising edge sampling in to get the data from from spi flash componenet?

That is why the sample in "Interfacing FT2232H Hi-Speed Devices To SPI Bus Application Note AN_114" (page 13) looks very odd:

//send WRITE command  O
utputBuffer[dwNumBytesToSend++] = MSB_FALLING_EDGE_CLOCK_BIT_OUT; 
OutputBuffer[dwNumBytesToSend++] = 2; 
OutputBuffer[dwNumBytesToSend++] = READ; 
//send address 
OutputBuffer[dwNumBytesToSend++] = MSB_FALLING_EDGE_CLOCK_BIT_OUT; 
OutputBuffer[dwNumBytesToSend++] = 7; 
OutputBuffer[dwNumBytesToSend++] = (BYTE)(address); 
//read data   

OutputBuffer[dwNumBytesToSend++] = MSB_FALLING_EDGE_CLOCK_BYTE_IN;     
OutputBuffer[dwNumBytesToSend++] = '\x01';   
OutputBuffer[dwNumBytesToSend++] = '\x00'


The question is why we are using MSB_FALLING_EDGE_CLOCK_BYTE_IN?

Why FALLING_EDGE instead of RAISING_EDGE?

 2 
 on: February 21, 2019, 10:48:01 AM 
Started by Pereubu123 - Last Post by Pereubu123
Data is typically clocked in and out on clock edges. 
Either the rising or falling edge can be used on transmit or receive.
In the 93C46D example, the EEPROM clocks data in and out on the rising edge.
I have my own selected SPI flash component, with clocking in (sampling) data on rising clock edge,
and clocking out data for that particular SPI memory chip on falling edge. Actually, input data is latched in on the rising edge of serial clock (C), and
output data is available from the falling edge of C.

What is confusing is:

(taken form AN_135 FTDI MPSSE Basics Version 1.1)
"In the 93C46D example noted above, the EEPROM clocks data in and out on the rising edge. 
In this case, the MPSSE should be configured for data transfer on falling edges for both transmit and receive. 
This allows the data out from both the MPSSE and the target device to stabilize before being clocked in on the next edge."
Now, I expect that I have to use opposite: MPSSE should be configured clocking in data on falling edge while clocking out data
on rising edge. But what is the meaning "This allows the data out from both the MPSSE and the target device to stabilize before
being clocked in on the next edge"?

So, is that Ok to follow the logic above to configure MPSSE to  latch input data on the rising edge of serial clock (C), and
output data to be  available from the falling edge of C.

 3 
 on: February 20, 2019, 05:32:41 PM 
Started by scorpioprise - Last Post by scorpioprise
Thank you, Kaetemi, I'll give a try to your solution, when I can move again with ESD project.

Can You explain a little the structure?

ESD_Project (top folder)
|-- Project( where exporting ) (subfolder level 1)
|-- EclipseProjectSrc (subfolder level 1)

Is your idea?

 4 
 on: February 20, 2019, 02:18:32 PM 
Started by bernie - Last Post by FTDI Community
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.

 5 
 on: February 19, 2019, 10:04:03 PM 
Started by TonyZ - Last Post by Kaetemi
The practical use of the glyph address in the font metric block is to allow the font bitmap to be loaded at any RAM address easily. Under ESE it is assumed that you'll manually write the address where the font bitmap is loaded into the address value, after having loaded the data into RAM_G.

Sample code exported from ESE should demonstrate this behaviour.

 6 
 on: February 19, 2019, 09:33:33 PM 
Started by scorpioprise - Last Post by Kaetemi
You can manually create an Eclipse project under a subdirectory of the ESD project, and link in all the required source files into the new project.

That will allow you to use the same source base from both ESD and Eclipse at the same time, with some manual project synchronization.

Copy the generated one into a subfolder called Project, edit in notepad, set up the paths to files in the project to PARENT-1-PROJECT_LOC, and use absolute paths for source files that are in the Libraries folder of your installation.

The #ifndef ESD_SIMULATION macro can be used to exclude any platform specific code, and put testing stubs in place instead.

 7 
 on: February 19, 2019, 11:01:19 AM 
Started by driver - Last Post by driver
I have been reading all the ANs about FTDI libMPSSE and FTD2XX library, and can not find any explicit description of the proper procedure to use a single MPSSE channel for both I2C and SPI, initialisation and deinitialisation. We are using FTDI2232H. Should we use FT_Purge, FT_Close and FT_Open (with FT_CyclePort if there are any errors), or is just a simple FtdiDevice.SetBitMode(0x00, 0x00); enough to reset the MPSSE interface (and libMPSSE library) to enable initialisation of other protocol?

 8 
 on: February 19, 2019, 08:27:54 AM 
Started by bernie - Last Post by bernie
Hi folks,

I’m using the FT201X and ftd2xx.dll with vb .net for my project. I’ve managed to get most needed functions to work neatly. That is interfacing my windows application with an MCU over I2C. But I’m encountering difficulties with two functions. These are ‘FT_GetStatus’ and ‘FT_GetQueueStatus’. These functions return 0 even when TXE# confirms the buffer is full. What I would like to know is if this is a known issue for the FT201 (assuming I’ve done everything correctly) or if this is the result of something else. I need atleast one of these functions to read the buffers efficiently. Thanks in advance.

 9 
 on: February 18, 2019, 10:59:35 AM 
Started by Attila - Last Post by scorpioprise
Be aware, caveat ahead!

The screen design will need some interaction with other code / hardware, so both approach will lead to some tweaks.

I found my way using EVE Screen Designer, then editing via Eclipse some of the generated code (which can be done in a easy manner) to obtain desidered behaviour.

 10 
 on: February 15, 2019, 04:59:22 PM 
Started by Attila - Last Post by Kaetemi
EVE Screen Editor is aimed at exploring the capabilities of the EVE platform, with a focus on experimenting directly with display list and coprocessor commands. It's helpful for quickly visually prototyping the instructions you need to achieve the result you want. Use this as a learning tool to work with EVE directly.

EVE Screen Designer is a very high level tool, and abstracts most of the complicated details of programming a UI away, providing a drag and drop experience to build a fully interactive UI. It's suitable for quickly prototyping an interactive UI, and the libraries deal with most of the platform specific intricacies for you.

Pages: [1] 2 3 ... 10