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 [4] 5 6 ... 10
 31 
 on: June 21, 2019, 02:20:36 PM 
Started by LOstrander - Last Post by LOstrander
I've added the ft900_registers.h file to the project, and now it at least gets through the function and loads the next screen without crashing.

However, this has pointed out a new issue: It doesn't seem to actually be setting the SPI Slave pins as such.  Specifically, the CLK line seems to be convinced it's an output, and idles high at 3.3V.  The SS and MOSI lines appear to be working.  The MISO line is hard to tell because it requires the CLK line to work for it to work.  When my SPI Master is disconnected from the MM900EV-LITE, it functions perfectly (besides the MISO for obvious reasons).

Does anyone have a pinout of the CN2 connector that explicitly shows which pin is which number?  I'm 99% sure I'm right in assuming it's left column odd, right column even, but I want to rule that out.  The next pin down (Pad 66) is my "Go" signal, and it works perfectly.

 32 
 on: June 21, 2019, 10:39:23 AM 
Started by gokhannsahin - Last Post by FTDI Community
Hello,

I assume you mean 3.1.2?
There is a new version slated for release by the end of the month, I believe this will resolve your issue.

Best Regards,
FTDI Community

 33 
 on: June 20, 2019, 04:15:18 PM 
Started by LOstrander - Last Post by LOstrander
I have a touchscreen and controller that I'm using as an HMI in a larger system.  I want to use the MM900EV-LITE as a SPI Slave to send some data from the touchscreen to the main controller.  For some reason, whenever I try to write to the SPI_DATA register, the controller resets.

I'm using the exact same code as the example from the FT9xx Toolchain for a SPI Slave.

Code: [Select]
#include "GoButton.h"
#include "FT_Platform.h"
#include "FT_ESD.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "ff.h"
#include "FT_Platform_FT900.h"

#ifndef ESD_SIMULATION
#include "ft900.h"
#include "ft900_spi.h"
#endif

ESD_FUNCTION(GoButton_SendData)
ESD_PARAMETER(fptr, Type = int)
void GoButton_SendData(fptr)
{
#ifndef ESD_SIMULATION
#define APP_BUFFER_SIZE (8)

#define SPIS_FIFOSIZE (64)

uint8_t* spis_dev_buffer;
uint8_t spis_dev_buffer_size;
uint8_t spis_dev_buffer_ptr;

    // Enable the SPI Slave device...
    sys_enable(sys_device_spi_slave0);

    // Set GPIO36 to SPIS0_CLK, GPIO37 to SPIS0_SS, GPIO38 to SPIS0_MOSI and GPIO39 to SPIS0_MISO...
    gpio_function(36, pad_spis0_clk);
    gpio_function(37, pad_spis0_ss);
    gpio_function(38, pad_spis0_mosi);
    gpio_function(39, pad_spis0_miso);

gpio_function(66, pad_gpio66);

    // Configure directions for the SPI slave 0 pins
    gpio_dir(36, pad_dir_input);
    gpio_dir(37, pad_dir_input);
    gpio_dir(38, pad_dir_input);
    gpio_dir(39, pad_dir_output);

gpio_dir(66, pad_dir_output);
gpio_pull(66, pad_pull_none);

    // Enable the SPI Slave Device...
    spi_init(
        SPIS0,          // Device
        spi_dir_slave,  // Direction
        spi_mode_0,     // SPI mode
        4);             // Ignored

    // Enable the FIFOs on the SPI Slave...
    spi_option(SPIS0, spi_option_fifo, 1);
spi_option(SPIS0,spi_option_fifo_size,SPIS_FIFOSIZE);
spi_option(SPIS0,spi_option_fifo_receive_trigger,1);

// Global variables initialization
//    spis_dev_buffer = buffer;
    spis_dev_buffer_size = APP_BUFFER_SIZE;
    spis_dev_buffer_ptr = 0;

    ...

//Setup data for transfer
uint8_t SendBuf[8] = {Diameter, Angle, Base >> 8, Base & 0xFF, Nose >> 8, Nose & 0xFF, Amount, Interval};
spis_dev_buffer = SendBuf;

//Load first byte
SPIS0->SPI_DATA = spis_dev_buffer[0];

//Tell the MCU to start transfering
gpio_write(66, 1);

//Wait for the Slave Select to go low
do{
asm_noop();
}
while(gpio_read(37) == true);

    // Load the SPIS0 buffer...
for(i=1;i<APP_BUFFER_SIZE;i++)
{
SPIS0->SPI_DATA = spis_dev_buffer[i];
}

//Make sure "Go button" is reset
gpio_write(66, 0);
#endif

}

From what I can tell, I'm not doing anything different besides leaving out the UART and looping functions from the example.  Is there something I missed?  or a file I need to include?

 34 
 on: June 20, 2019, 02:49:58 PM 
Started by gokhannsahin - Last Post by gokhannsahin
Hi,
I'm using the last version is v3.2.1.

 35 
 on: June 20, 2019, 12:03:57 PM 
Started by gokhannsahin - Last Post by FTDI Community
Hello,

What version of ESE are you using?

Best Regards,
FTDI Community

 36 
 on: June 20, 2019, 11:54:50 AM 
Started by Tycoon - Last Post by FTDI Community
Hello,

Thanks for sending a follow up to your question explaining the workaround, I'm sure this will be a good resource for the Community.

Many thanks,
FTDI Community

 37 
 on: June 20, 2019, 08:39:53 AM 
Started by Tycoon - Last Post by Tycoon
Hello !

I finally found a workaround ! For posteriority, I'll explain what I did to obtain the correct behavior.

It was indeed a software problem, in particular the problem seems to come from the LibMPSSE-I2C library. Basically, you need to recompile the lib after activating a workaround in the source code. It seems some guy named Grahal had the same issue and submitted a fix. The issue has to do with an SCL glitch, but I'll admit I'm not sure of the detail.

So, once you have download the source files of the library, open the ftdi_i2c.c file in the TopLayer folder. On line 1400, disable the proposition 2 by replacing the
Code: [Select]
if 1 with
Code: [Select]
if 0 Just below that, on line 1412, enable the proposition 3 by replacing the
Code: [Select]
if 0 with
Code: [Select]
if 1
Alternatively, you can activate the proposition 1 on line 1378 instead, it actually seems to work better for me.

Note that this fixes the FastRead function, so I'm not sure it'll fix the issue if you don't use
Code: [Select]
I2C_TRANSFER_OPTIONS_FAST_TRANSFER_BYTES
Recompile the project, and it should now work. If you use GCC, there's a build folder with a makefile and a script. If you use MSVC, there's some changes to do before it will compile :

  • In ftdi_infra.c, comment out every declaration and definition of my_init and my_exit
  • In ftdi_infra.h, replace the likely(x) and unlikely(x) macro so that they don't do anything because __builtin_expect doesn't exist in MSVC

Finally, place yourself in the LibMPSSE folder and compile using
Code: [Select]
cl /LD /I../External/Windows/CDM /ICommon/inc /IInfra/inc /IMiddleLayer/inc /ITopLayer/I2C/inc Common/src/ftdi_common.c Infra/src/ftdi_infra.c MiddleLayer/src/ftdi_mid.c TopLayer/I2C/src/ftdi_i2c.c /FeLibMPSSE-I2C.dll or similar to create the shared library.

Maybe it'll help other people !

Cheers

 38 
 on: June 20, 2019, 07:17:50 AM 
Started by gokhannsahin - Last Post by gokhannsahin
Hi everyone,
I can't upload a font(.ttf file) to eve screen editor, it always gives an error that is "Freetype not available"
I guess that this new version has a bug because there was no problem in other versions.


 39 
 on: June 18, 2019, 05:58:53 PM 
Started by atx - Last Post by atx
In my application using an FT81x, I like to use different images.  For speed reasons, I would like to upload these after power up into RAM_G at differnet addresses.  The images are of different sizes, such as 400 x 180 and 600 x 200, etc., thus rather larger but still fit easily within the 1MB general purpose RAM.  However, any of these images loaded into RAM_G under an address other than 0x0 (using BITMAP_SOURCE) will either be shifted in a weird way or does not show up at all.  Only when I load it at address 0x0, the image will show.  I also used any of the various examples available to verify this behaviour, but they all fail as soon as I change the destination address.  Some examples with smaller images work with an address such as 0x600 but also fail when this is changed to a higher address such as 0x1000.  This not an alignment issue, as I used aligned addresses.  What am I doing wrong?? The Programming Guide does not help as the BITMAP_SOURCE command only requires a 2 byte alignment for the bitmap format RGB565 that I am using. Interestingly, any example only uses address 0x0 for images.  But what is the purpose of BITMAP_SOURCE if it only works for RAM_G address 0?

 40 
 on: June 17, 2019, 02:07:05 PM 
Started by aferquez - Last Post by FTDI Community
Hello,

You can use a Logic Analyser to capture the data on the SPI pins.

Best Regards,
FTDI Community

Pages: 1 2 3 [4] 5 6 ... 10