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 ... 8 9 [10]
 91 
 on: March 22, 2019, 04:38:07 PM 
Started by Pereubu123 - Last Post by FTDI Community
Hi,

The EEPROM protocol is slightly different from standard SPI such as that used by MCUs and other sensors. We'll need to check why that edge was used in that particular app note but in general for standard mode 0 SPI you would use IN on the rising edge and OUT on the falling edge in your MPSSE commands, as you mentioned. For example, we use these in our libMPSSE library when you select mode 0 (see ftdi_spi.c in the source for reference).

Best Regards, FTDI Community

 92 
 on: March 22, 2019, 04:28:07 PM 
Started by scorpioprise - Last Post by FTDI Community
Please note that our 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

The FT90x library driver for I2C only supports 8-bit addressing.
However, you could take a look at FT90x UVC Webcam Example. The OV5640 module code includes a set of subroutines to allow 16-bit addressing on the I2C bus. These may be reused for other projects.
The source code is downloadable at the link above.

This should help you access the 24LC64 64k range.

The device addressing of both EEPROMs are very similar. The control byte format starts with 1010.

Maybe someone else on the Bridgetek Community can help further with this.

Best Regards,
FTDI Community

 93 
 on: March 21, 2019, 03:24:27 PM 
Started by driver - Last Post by FTDI Community
Hello,

How long do you leave the device after closing and before re-opening? It may take some time for the port to close and Windows to release the handle.

Do you get an error when you try to re-open it as I2C?

If you write the code in D2xx, you can reset the bitmode by calling FtdiDevice.SetBitMode(0x00, 0x00); and then SetBitMode back into MPSSE mode. (you could probably even just start sending the new commands after ensuring that you had read all the existing data which had come back from the device and sending GPIO commands to configure the data and direction of the AD and AC buses but resetting the bit mode will provide a cleaner start).

Best Regards, FTDI Community




 94 
 on: March 20, 2019, 04:31:36 PM 
Started by Rajesh@sys - Last Post by FTDI Community
Hello,

This is not possible because D0 to D7 bidirectional FIFO data are used for both read and write operations.

Best Regards,
FTDI Community

 95 
 on: March 20, 2019, 02:02:41 PM 
Started by dbell - Last Post by FTDI Community
Hello,

The FT602 UVC Class SuperSpeed USB Bridge device provides a 32 bit parallel interface to application hardware and a UVC class USB port, allowing captured data to be transferred. The 32-bit parallel FIFO interface is for data streaming and there is a UART interface for control path configuration. Typical applications for the FT602 would be a USB 3.1 Digital Video Camera Interface or USB 3.1 Digital Camera.

Note that we have other SuperSpeed USB 3.0 solutions - The FT600 (16-bit FIFO Bus) and FT601 (32-bit wide parallel FIFO interface) supports 2 parallel slave FIFO bus protocols, with data bursting rate up to 400MBps.

If you want to send an email to support1@ftdichip.com I can provide some additional information.

Regards,
FTDI Community

 96 
 on: March 20, 2019, 12:53:39 PM 
Started by scorpioprise - Last Post by FTDI Community
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

 




 97 
 on: March 19, 2019, 05:56:15 PM 
Started by driver - Last Post by driver
I found there are problems with libMPSSE.dll v0.6 (win) channel init and deinit (I used it with FTDI2232H), as it seemed in my initial tests.

When using a MPSSE channel for SPI twice (SPI_InitChannel and SPI_OpenChannel), the MPSSE channel will not initialise to SPI the second time if SPI_CloseChannel(handle) is used (followed with a Cleanup_libMPSSE). Using the returned handle, FT_WriteGPIO returns Invalid Handle status.

When using only Cleanup_libMPSSE to deinitialise SPI channel, not using SPI_CloseChannel, SPI works fine after multiple init deinit sequences. But then the I2C does not initialise after using SPI. And my task requires combined SPI/I2C usage for the channel.

Any ideas?
At the moment, rewriting the I2C part to use FTD2XX.dll seems like the only solution for this problem. Do you know of a way the libMPSSE.dll can be used to access SPI and I2C devices on the same MPSSE channel?

 98 
 on: March 19, 2019, 04:43:20 PM 
Started by scorpioprise - Last Post by scorpioprise
Hi there, have you any idea on how to detect that you have a long click on (for instance) a imagebutton ( and do something different in your code ) ?
It involves the down signal, ok, but how would you modify it?


 99 
 on: March 19, 2019, 03:51:46 PM 
Started by scorpioprise - Last Post by scorpioprise
Hi Everybody, I'm working on my custom board, so it's not a good starting point....
I have a 64K I2C serial eeprom. But I don't really understand what's wrong...

Of course, I tested the example on the demo board (MM900EV1A) and worked. (2K eeprom)

First problem, No read - no write.
The location address is 12bit long, so I got the source and altered, but no success.

Code: [Select]
int8_t i2cm_write_twoByte(const uint8_t addr, const uint16_t loc,
const uint8_t *data, uint16_t number_to_write) {
int8_t ret = 0;

if (isHighSpeed) {
/* In high speed mode, the following sequence has to be done before each data transfer
Write Master code 0x09 to I2CMSA and the HIGH SPEED command to I2CMCR */
I2CM->I2CM_SLV_ADDR = 0x09;
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_HS | I2C_FLAGS_RUN;

/* Wait until I2CM is no longer busy */
if (i2c_wait_for()) { /* An Error Occurred */
ret = -1;
}
}

if (ret == 0) {
/* Write slave address to SA */
I2CM->I2CM_SLV_ADDR = addr;
/* Write command byte address MSB to BUF */
I2CM->I2CM_DATA = (uint8_t) ((loc & 0xFF00) >> 8);

/* Check that the bus is not occupied by another master
(this step is not needed in single-master system or in high speed mode since
arbitration takes place during transmission of the master code) */
if (isHighSpeed == 0) {
while (I2CM->I2CM_CNTL_STATUS & MASK_I2CM_STATUS_BUS_BUSY) {
}
}

/* Write command to I2CMCR to send Start and command byte. */
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_START | I2C_FLAGS_RUN;
if (i2c_wait_for()) { /* An Error Occurred */
ret = -1;
}
}
if (ret == 0) {
/* Write command byte address LSB to BUF */

I2CM->I2CM_DATA = (uint8_t) (loc & 0xFF);
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_RUN;
if (i2c_wait_for()) { /* An Error Occurred */
ret = -1;
}
}

if (ret == 0) {
if (number_to_write) {
while (number_to_write-- && ret == 0) {
/* Write command to I2CMCR to send data byte. */
I2CM->I2CM_DATA = *data++;
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_RUN;
if (i2c_wait_for()) { /* An Error Occurred */
ret = -1;
}
}
}
}

/* Write command to I2CMCR to send Stop. */
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_STOP;
if (ret == 0) {
i2c_wait_for();
}

return ret;
}

Code: [Select]
int8_t i2cm_read_twoByte(const uint8_t addr, const uint16_t loc, uint8_t *data,
uint16_t number_to_read) {
int8_t ret = 0;

if (isHighSpeed) {
/* In high speed mode, the following sequence has to be done before each data transfer
Write Master code 0x09 to I2CMSA and the HIGH SPEED command to I2CMCR */
I2CM->I2CM_SLV_ADDR = 0x09;
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_HS | I2C_FLAGS_RUN;

/* Wait until I2CM is no longer busy */
if (i2c_wait_for()) {
ret = -1;
}
}

if (ret == 0) {
/* Write slave address to SA */
I2CM->I2CM_SLV_ADDR = addr;
/* Write command byte address to BUF */
I2CM->I2CM_DATA = (uint8_t) ((loc & 0x1f00) >> 8);

/* Check that the bus is not occupied by another master
(this step is not needed in single-master system or in high speed mode since
arbitration takes place during transmission of the master code) */
if (isHighSpeed == 0) {
while (I2CM->I2CM_CNTL_STATUS & MASK_I2CM_STATUS_BUS_BUSY) {
}
}

/* Write command to I2CMCR to send Start and command byte. */
I2CM->I2CM_CNTL_STATUS =
I2C_FLAGS_START | I2C_FLAGS_RUN | I2C_FLAGS_ACK;

if (i2c_wait_for()) {
ret = -1;
}
}
if (ret == 0) {
I2CM->I2CM_DATA = (uint8_t) (loc & 0x00ff);
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_RUN | I2C_FLAGS_ACK;
if (i2c_wait_for()) {
ret = -1;
}
}
if (ret == 0) {
/* Write slave address to SA with R operation */
I2CM->I2CM_SLV_ADDR = addr | 0x01;

if (number_to_read <= 1)
/* Receive with a NACK */
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_START | I2C_FLAGS_RUN;
else
/* Receive with an ACK */
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_START | I2C_FLAGS_RUN
| I2C_FLAGS_ACK;

if (i2c_wait_for()) {
ret = -1;
}
}

if (ret == 0) {
while (number_to_read) {
*data++ = I2CM->I2CM_DATA;
number_to_read--;

if (number_to_read) {
if (number_to_read == 1)
/* Last one, Receive with a NACK */
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_RUN;
else
/* Receive with an ACK */
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_RUN | I2C_FLAGS_ACK;

/* Write command to I2CMCR to read data byte.
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_RUN; */
if (i2c_wait_for()) {
ret = -1;
break;
}
}
}
}

/* Write command to I2CMCR to send Stop. */
I2CM->I2CM_CNTL_STATUS = I2C_FLAGS_STOP;
if (ret == 0) {
i2c_wait_for();
}

return ret;
}

Memory is Microchip 24LC64, 5 pin SOT23 (no hardware address).

Any idea where to look for the problem?

 100 
 on: March 19, 2019, 10:33:14 AM 
Started by Rajesh@sys - Last Post by Rajesh@sys
thank you very much for your reply.

<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. >




i know this one.


are they independent ??


can we perform READ and WRITE at same time ?

Pages: 1 ... 8 9 [10]