FTDI Community

Please login or register.

Login with username, password and session length.
Advanced Search  


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 [2] 3 4 ... 28
Discussion - Software / Re: FT813 initialization
« on: May 11, 2020, 02:52:07 PM »

We recommend to read the REG_ID to ensure the FT813 is ready and it is also a good way to ensure the SPI communications are working.

Here is a basic start-up flow. Initially, if you try the parts in red text and ensure that you get the 0x7C back and that REG_CPU_RESET goes to 0 then this will give a good indication that the communication is working. 

If your code gets stuck at the REG_ID read, could you post or send us a logic analyser waveform of all your SPI lines

Best Regards, FTDI Community

MCU_PDlow();                                                                // PD low to reset device                                                               
    MCU_PDhigh();                                                               // PD high again

    // ---------------------- Optional clock configuration ---------------------   

    // Un-comment this line if using external crystal. Leave commented if using internal oscillator.
    // Note that most FTDI/BRT modules based on FT800/FT801 use an external crystal
    // EVE_CmdWrite(0x44, 0x00);           // 0x44 = HostCMD_CLKEXT

    // You can also send the host command to set the PLL here if you want to change it from the default
    // of 48MHz (FT80x) or 60MHz (FT81x)
    // The command would be called here before the Active command wakes up the device   
    // ---------- Wake FT8xx and delay to allow device to start-up -------------   
    EVE_CmdWrite(FT81x_ACTIVE, 0x00);                                           // Sends 00 00 00 to wake FT8xx
    MCU_Delay_500ms();                                                          // 500ms delay with no access over SPI during delay

    // --------------- Check that FT8xx ready and SPI comms OK -----------------
    while (EVE_MemRead8(REG_ID) != 0x7C)                                        // Read REG_ID register (0x302000) until reads 0x7C
    while (EVE_MemRead8(REG_CPURESET) != 0x00)                                  // Ensure CPUreset register reads 0 and so FT8xx is ready   

    // ------------------------- Display settings ------------------------------

    // WQVGA display parameters
    lcdWidth   = 800;                                                           // Active width of LCD display
    lcdHeight  = 480;                                                           // Active height of LCD display
    lcdHcycle  = 928;                                                           // Total number of clocks per line
    lcdHoffset = 88;                                                            // Start of active line
    lcdHsync0  = 0;                                                             // Start of horizontal sync pulse
    lcdHsync1  = 48;                                                            // End of horizontal sync pulse
    lcdVcycle  = 525;                                                           // Total number of lines per screen
    lcdVoffset = 32;                                                            // Start of active screen
    lcdVsync0  = 0;                                                             // Start of vertical sync pulse
    lcdVsync1  = 3;                                                             // End of vertical sync pulse
    lcdPclk    = 2;                                                             // Pixel Clock
    lcdSwizzle = 0;                                                             // Define RGB output pins
    lcdPclkpol = 1;                                                             // Define active edge of PCLK
    EVE_MemWrite16(REG_HSIZE,   lcdWidth);   
    EVE_MemWrite16(REG_HCYCLE,  lcdHcycle);   
    EVE_MemWrite16(REG_HOFFSET, lcdHoffset);   
    EVE_MemWrite16(REG_HSYNC0,  lcdHsync0);   
    EVE_MemWrite16(REG_HSYNC1,  lcdHsync1);   
    EVE_MemWrite16(REG_VSIZE,   lcdHeight);   
    EVE_MemWrite16(REG_VCYCLE,  lcdVcycle);   
    EVE_MemWrite16(REG_VOFFSET, lcdVoffset);   
    EVE_MemWrite16(REG_VSYNC0,  lcdVsync0);   
    EVE_MemWrite16(REG_VSYNC1,  lcdVsync1);   
    EVE_MemWrite8(REG_SWIZZLE,  lcdSwizzle);   
    EVE_MemWrite8(REG_PCLK_POL, lcdPclkpol);   
    FT81x_GPIO = EVE_MemRead8(REG_GPIO);                                        // Read the  GPIO register for a read/modify/write operation
    FT81x_GPIO = FT81x_GPIO | 0x80;                                             // set bit 7 of  GPIO register (DISP) - others are inputs
    EVE_MemWrite8(REG_GPIO, FT81x_GPIO);                                        // Enable the DISP signal to the LCD panel
    // ---------------------- Touch and Audio settings -------------------------

    EVE_MemWrite16(REG_TOUCH_RZTHRESH, 1200);                                   // Eliminate any false touches

    EVE_MemWrite8(REG_VOL_PB, ZERO);                                            // turn recorded audio volume down
    EVE_MemWrite8(REG_VOL_SOUND, ZERO);                                         // turn synthesizer volume down
    EVE_MemWrite16(REG_SOUND, 0x6000);                                          // set synthesizer to mute

    // ----------------- First Display List to clear screen --------------------

    ramDisplayList = RAM_DL;                                                    // start of Display List
    EVE_MemWrite32(ramDisplayList, 0x02000000);                                 // Clear Color RGB sets the colour to clear screen to black

    ramDisplayList += 4;                                                        // point to next location
    EVE_MemWrite32(ramDisplayList, (0x26000000 | 0x00000007));                  // Clear 00100110 -------- -------- -----CST  (C/S/T define which parameters to clear)

    ramDisplayList += 4;                                                        // point to next location
    EVE_MemWrite32(ramDisplayList, 0x00000000);                                 // DISPLAY command 00000000 00000000 00000000 00000000 (end of display list)

    EVE_MemWrite32(REG_DLSWAP, DLSWAP_FRAME);                                   // Swap display list to make the edited one active

    EVE_MemWrite8(REG_PCLK, lcdPclk);                                           // Now start clocking data to the LCD panel
    EVE_MemWrite8(REG_PWM_DUTY, 127);


Discussion - Software / Re: FT_Prog on Windows 10
« on: May 11, 2020, 11:42:56 AM »

Please try this beta version:

FT_Prog_v0.0.94.440 Installer.zip

Best Regards,
FTDI Community

Discussion - Drivers / Re: FTDI VCP driver on macOS Catalina
« on: May 07, 2020, 01:37:20 PM »

Thanks for the link! This is a very interesting piece of software and may be beneficial for other customers on the form whilst we are resolving the signature issue with our driver.

Best Regards,
FTDI Community

Discussion - Software / Re: Using coprocessor (FT813)
« on: May 06, 2020, 04:28:04 PM »

Sorry the previously example was from a co-processor list (I will link the application note at the end).

So you mean I don't have to write anything myself? If the coprocessor writes these 2 instructions,
then I have to leave room for these instructions, and then at the end I will write the instructions at offset 8
(4 for clear_color + 4 for clerar(1,1,1)?

You would write the commands to RAM_CMD and the co-processor would deal with writing the normal DL commands to RAM_DL

I don't understand this part. What does it do? Do I need it to draw a slider? It looks like it will draw a point.
Is it written in RAM_CMD or RAM_DL? I can write RGB(0,0,255) directly to RAM_DL, so it doesn't look like a
coprocessor command. In my snippet below I

This was just an illustrative example, you would write your slider command here.

You would write the END, DISPLAY and SWAP commands to the co-processor and again this deals with handling normal DL commands.

[update REG_CMD_WRITE to point to end of new commands]

How do I do that? I can read where the REG_CMD_WRITE is by rd16(REG_CMD_WRITE + RAM_REG);
but what should I do with the value?

The idea here is that you update REG_CMD_WRITE with the total length of the commands you have issued to the co-processor then you wait until REG_CMD_WRITE = REG_CMD_READ signalling the commands have been accepted.

Im going to link some useful application notes which cover how all the low level EVE transfers are intended to work:

Application note BRT_AN_006 shows how the SPI transfers work down to bit level and how the data is formatted into the API used by the EVE device itself. This low-level framework is used as the basis for BRT_AN_008. Although written specifically for PIC, the same data transfers and formatting can be used on other MCUs.

Application note BRT_AN_007 extends the principles shown in BRT_AN_006 to demonstrate how these low level transfers can be used for various widgets and common operations such as text, bitmaps and touch controls.

Application note BRT_AN_008 explains how to create a library for EVE on your MCU, using the PIC18F device as an example. It uses various code layers to provide an intuitive framework so that the main application can use high-level commands from the EVE Programmers Guide whilst the lowest layers translate these to the byte level transfers for the MCU’s SPI Master Interface. The code supports the FT80x and FT81x series.

Best Regards,
BRT Community

Discussion - Software / Re: Using coprocessor (FT813)
« on: May 05, 2020, 04:52:17 PM »

It looks like your code is just writing the CMD_SLIDER command and its variables with COP_SLIDER = 1, is this correct?
The general structure of a co-processor list when generating a screen is as shown below denoting
the typical starting and ending procedures:
Code: [Select]
[Await REG_CMD_READ == REG_CMD_WRITE and read value of these registers]
#start procedure
CMD_DL_START // Tells co-pro to begin writing DL at RAM_DL+0
CLEAR_COLOR_RGB // Co-processor writes this instruction to the DL
CLEAR(1,1,1) // Co-processor writes this instruction to the DL

#co-pro commands

#end procedure
DISPLAY // Co-processor writes this instruction to the DL
CMD_SWAP // Co-processor writes REG_DL_SWAP
[update REG_CMD_WRITE to point to end of new commands]

Note that the co-processor will not process any of the commands until the second-last step
(writing REG_CMD_WRITE). The processing is complete and the screen will update only after the
last condition (read and write pointers equal) becomes true

Best Regards,
FTDI Community


If the host PC is connected to the internet, the driver will be automatically downloaded and installed via Windows Update.

The other option is to preload the drivers on the host PC using the setup executable.

Best Regards,
FTDI Community


Yes, the maximum throughput of 52.8Mpbs is to calculate the Data phase throughput, but the data size is not 16 bits, it is 10K bytes.

If CMD and ADDR phase are counted into the calculation of Max Throughput, 17.6Mbps is a reasonable payload on the FT4222H device. 

Best Regards,
FTDI Community


Thanks for your question, I have relayed this to the development team to have a look at.

Best Regards,
FTDI Community


Curiously neither FT4222_I2CSlave_GetRxStatus() or FT4222_I2CSlave_Read() are denoted as allowing for return codes which would indicate a USB disconnected.

In this case I would suggest calling  the D2XX function FT_GetStatus(), this will also return the number of bytes in the RX queue, but it should throw an FT_DEVICE_NOT_FOUND or FT_IO_ERROR on a USB disconnect.

Best Regards,
FTDI community

Discussion - Drivers / Re: FTDI VCP driver on macOS Catalina
« on: May 01, 2020, 04:37:55 PM »

Apple are moving from what are called Kernel Extentions (.kexts) to what are called Driver Extensions (.dexts) for the implementation of drivers starting in macOS Catalina (10.15). Currently .kexts are still supported in macOS Catalina, however after the beta release they issued an update which stopped our driver from loading. This update required our driver (FTDIUSBSerialDriver.kext) to be re-signed and notarized, we completed this process with an updated Apple Developer ID. Unfortunately when Apple issued our new Developer ID to re-sign and notarize the driver package they did so without the .kext support option enabled (as .kexts are being deprecated it is no longer automatically included). This is why there is a code signature issue with our driver, currently we are waiting on Apple issuing us with the correct Developer ID to be able to sign .kexts for macOS Catalina.

As such our current VCP driver available on the website has a signature issue and wont load. However if the device you are using implements a default FTDI VID/PID combination it should be picked up by the inbuilt AppleUSBFTDI.dext driver and present accordingly in the ‘/dev’ folder on your system in the following form:

Best Regards,
FTDI Community 


We don't specifically support Monodevelop in Linux and have no knowledge of it, but maybe there are other community forum members who can help you.

The loopback example was written and built using Microsoft Visual Studio.
I would recommend testing this out on a Windows PC.
In addition, the FTD2XX_NET.DLL is provided for the Windows platform:


Source code for the wrapper is provided so you could develop your own C# wrapper which will work on Monodevelop in Linux.

Best Regards,
FTDI Community

Discussion - Software / Re: VNC2 ports
« on: May 01, 2020, 09:12:55 AM »

Welcome to the FTDI Community,

Those changes seem fine.

      // UART_TXD to pin 29 as Output.
      vos_iomux_define_output(29, IOMUX_OUT_UART_TXD);
      // UART_RXD to pin 30 as Input.
      vos_iomux_define_input(30, IOMUX_IN_UART_RXD);
      // UART_RTS_N to pin 31 as Output.
      vos_iomux_define_output(31, IOMUX_OUT_UART_RTS_N);
      // UART_CTS_N to pin 32 as Input.
      vos_iomux_define_input(32, IOMUX_IN_UART_CTS_N);

If you have access to the default UART pins, it would be worth making sure your serial device can communicate with those using default firmware first of all. Note that RTS and CTS must be used as the device is set by default for hardware flow control and so no data will flow if not asserted (we always recommend this to avoid data loss).

Best Regards, FTDI Community

Discussion - Drivers / Re: FTD2XX_NET for UWP Applications
« on: April 30, 2020, 05:07:02 PM »

Which type of host platform are you running the code on? Is it an x86, x64 or an ARM system?

Best Regards, FTDI Community

Hello Allen,

Our drivers may have a dependency on Windows Timer Resolution.
Some applications like Chrome for example may change the Windows Timer Resolution which can have an effect on all software that uses it.
We think it’s a bad practise from Microsoft to allow for the Windows Timer Resolution to be changed by applications, but it is out of our control.

The screen saver issue is not something that we have encountered before. Maybe disabling it is an option, or take a look at the other Windows settings?

Please take a look at the standard I2C examples provided with LibFT4222.

Best Regards,
FTDI Community

Discussion - Drivers / Re: Embedded Host FT232RQ
« on: April 30, 2020, 01:49:43 PM »

The FT232R uses vendor class over USB and so we have our own API and driver. If you need to host the device from your own MCU which is not covered by one of our drivers, then you can request the API under NDA from us. Please send us an email at support1@ftdichip.com if you would like to discuss obtaining these under NDA.

Best Regards, FTDI Community

Pages: 1 [2] 3 4 ... 28