Hi,
I got the issue that the FT_ReadGPIO read all bit values as high(255) after setting up the initial value as low(0) for all bits.
first, I set up the GPIO initial value as low and direction as input by FT_WriteGPIO(handle, 0, 0);
then, I use the FT_ReadGPIO(&read_value), I always get 255 when the GPIOH has no connection.
If I connect one of the GPIOH to the GND pin, the reading will change to low, it comes back high when removing the connection.
Is it the expected behavior of the GPIO within LibMPSSE?
My environment:
LibMPSSE version: 1.0.5
Device:232H
OS: Windows
Pin usage: SPI for GPIOL[0:3], GPIO for GPIOH[4]
Best Regards,
Tony
- May 23, 2024, 05:57:54 pm
- Welcome, Guest
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
21
General Category / Discussion - Software / initial value is wrong by using Read GPIO within LibMPSSE
on: April 09, 2024, 04:17:38 am
|
||
Started by TonySH - Last Post by TonySH | ||
22
on: March 29, 2024, 04:37:00 pm
|
||
Started by allenhuffman - Last Post by FTDI Community | ||
Hello,
Please confirm which version of the D2xx driver and LibFT4222 that you are using? Are you using custom FT4222H hardware? Do you see the same issue with our UMFT4222EV-D? Could the I2C slave be at fault rather than the FT4222H I2C master? When this happens maybe you can perform a software reset rather than having to force quit or restart? See FT4222_ChipReset API. You can also try these D2xx based APIs: FT_Purge FT_ResetDevice FT_ResetPort FT_Rescan FT_Reload FT_CyclePort Best Regards, FTDI Community |
23
on: March 28, 2024, 09:19:04 pm
|
||
Started by allenhuffman - Last Post by allenhuffman | ||
We have systems communication over I2C with a Windows machine acting as master. The system will chug along doing millions of messages over weeks or months just fine, or it may run for a few hours then get an FTDI error. When this happens, the program is usually locked up (spinny blue donut) and we have to force quit or restart Windows.
When that happens, I do not expect there is anything we can do about it. But other times, we'll sometimes get back the error 1011 (failed to read device) error and not lock up, but all further I2C writes will be failing with errors. Do we have any hope of finding a way to prevent this from happening? |
24
General Category / Discussion - Drivers / Re: When will libft4222 be available for 64Bit ARM (aarch64)?
on: March 28, 2024, 04:17:53 pm
|
||
Started by a4711 - Last Post by FTDI Community | ||
Hello,
Unfortunately the LibFT4222 source code can't be shared as it's exposes secrets of our vendor class devices. Please contact us via email on support1@ftdichip.com and we'll contact our R&D team to see if we can provide a 64 Bit (aarch64) build. Best Regards, FTDI Community |
25
on: March 27, 2024, 08:58:33 pm
|
||
Started by a4711 - Last Post by a4711 | ||
It is becoming more and more common to install a 64 Bit OS on a Raspberry. Libft4222 is available for ARMv8 32 Bit architecture, but not for 64 Bit (aarch64). When will you publish it or when will you publish the source code of LibFT4222 so that we can compile it on any architecture?
Thanks. |
26
on: March 21, 2024, 03:32:52 pm
|
||
Started by mnecetinkaya - Last Post by FTDI Community | ||
Hello,
The extra bytes may be due to lack of biasing on the RS485 transceiver. If you could email into support1@ftdichip.com we can share the RS485 biasing schematic that will be able to help you. Best Regards FTDI Community |
27
on: March 21, 2024, 01:18:18 pm
|
||
Started by mnecetinkaya - Last Post by mnecetinkaya | ||
Hi everyone,
I have a problem like I mention in title shortly. I designed a board to communicate between pc and a device which use RS485. I can communicate but every time receive a data it comes with a FE or FF byte as prefix. I'm using FT2232HQ with ADM3485EARZ-REEL7 on my board. Then I used USB-COM485-PLUS2 and I compared the waveform of the two converters. Even though the waveforms are same, I did not receive any extra byte while using USB-COM485-PLUS2. I wonder if I get schematic of COM485-PLUS2? Or does anyone have an idea about that situation? |
28
General Category / Discussion - Hardware / Re: RXD pin of FT232R and FT232H is HIGH when not connected
on: March 21, 2024, 12:21:42 pm
|
||
Started by brumbarchris - Last Post by brumbarchris | ||
Thank you.
Cristian |
29
General Category / Discussion - Hardware / Re: RXD pin of FT232R and FT232H is HIGH when not connected
on: March 21, 2024, 10:48:38 am
|
||
Started by brumbarchris - Last Post by FTDI Community | ||
Hello,
Yes, there are internal pullups on the RXD lines of FT232R and FT232H. the typical value is 75 KΩ. You can find more information in 5.3 of the FT232H datasheet. Best Regards FTDI Community |
30
on: March 20, 2024, 05:01:36 pm
|
||
Started by brumbarchris - Last Post by brumbarchris | ||
Hello,
I have two FTDI cables based on the FT232H (a C232HMDDHSL-0 and a C232HD-DDHSP-0) and one based on the FT232R (TTL-232R-3V3). In active mode (device enumerated after EEPROM read) the RXD pin is HIGH on these devices (some 2.5V on the FT232H based cables and 3.3V on the FT232R based cable). Now, in this mode, this pin operates as an input. In order to be high, it must have a pull-up. Is there any information available with regards to this pull-up (its value)? The datasheet of the FT232R might infer the presence of a 200k pull-up on this pin, with this statement which is present after Table 5.10: Quote ** Only input pins have an internal 200KΩ pull-up resistor to VCCIO But there is nothing on this in the FT232H datasheet (although it talks about pull-ups on various other pins, the RXD pin is not mentioned). I am familiar also with AN_184 FTDI Device Input Output Pin States, but that didn't help either, it just indicates that in in active mode the RXD pin is configured as "Function". Regards, Cristian |