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: December 11, 2019, 11:38:53 AM 
Started by SuperGraham - Last Post by FTDI Community
Hello,

One thing you could do is to check with USBview as shown below. This allows you to see if a device returns descriptors correctly. If the details such as idVendor and idProduct (VID and PID) are zeros then the device has not been able to communicate properly with the PC.

https://www.ftdichip.com/Support/Utilities.htm#MicrosoftUSBView

Best Regards,
FTDI Community

 2 
 on: December 10, 2019, 11:16:16 PM 
Started by kzxela - Last Post by kzxela
We are using the Modbus protocol over a USB-serial connector (ID 0x0856:0xac25) on Linux using the ftdi-sio driver using RS-485 bus. We are using libmodbus for Modbus communications over RS-485.

For our purposes, we need to be able to respond to broadcast messages (this breaks the Modbus standard, but we control all of the devices so it works for us, this is for figuring out what devices are out there on the bus).

Responding to broadcast messages over the RS-485 bus will lead to collisions which we mitigate by adding random timeouts for responses.
This works great for us, however, sometimes we notice this causes the link to stop working (won't respond to reads/writes), this behavior however is transient because if we just issue a retry read/write, it will work for us.

The question we have is that is there some internal mechanism in the ftdi-sio driver or the hardware that has some sort of timeout in response to collissions that will cause the link not to respond for an amount of time? We ensure the random sleep time never exceeds 1 second for us, and while we do respond to broadcast messages, we only do so for reads, for writes, we do not so there should be no collisions. However, we see that sometimes even broadcast writes with no response fails to even reach the device over serial.  We ensure that this is not a faulty link by doing a stress test of reads/writes over a few days but with no broadcast. If we introduce broadcast reads/writes, this transient behavior of not responding seem to occur randomly. Any ideas is greatly appreciated.

 3 
 on: December 10, 2019, 08:42:21 PM 
Started by SuperGraham - Last Post by SuperGraham
I bought a CMU USB RS485 TTL CONVERTER FTDI - https://www.communica.co.za/products/cmu-usb-rs485-ttl-converter-ftdi.

My computer is running Windows 10 Pro x64.  I connected the converter using the correct USB cable - https://www.communica.co.za/products/printer-cable-usb-1-8m-tt.  When connected, the device was first shown as ‘Unknown USB Device (Device Descriptor Request Failed)’ so I installed the drivers from here - https://www.ftdichip.com/Drivers/VCP.htm.  The device then showed as a ‘USB Serial Converter’, but the device shows the following error and doesn’t appear to work.

This device cannot start. (Code 10)
A request for the USB device descriptor failed.

The drivers loaded are as follows:
C:\Windows\System32\DRIVERS\edevmon.sys
C:\Windows\System32\DRIVERS\ftdibus.sys
C:\Windows\System32\ftbusui.dll
C:\Windows\System32\ftd2xx.dll
C:\Windows\System32\FTLang.dll
C:\Windows\SysWOW64\ftd2xx.dll

I’m inclined to think that the converter is damaged, unless you have some useful advice?  At this point it’s not connected to anything.  I'm out of ideas at the moment.

 4 
 on: December 10, 2019, 03:46:08 PM 
Started by asusrog - Last Post by cioma
Did you configure FT230X as self-powered device using FT_Prog?

 5 
 on: December 10, 2019, 02:09:11 PM 
Started by maxwell123 - Last Post by maxwell123
I want to use an FT245 with a terminal program only, assuming that the terminal can send all characters (0x00 to 0xff) can this be done?  If so what are the commands available.
I only need to set/reset the 8 data lines.

Thanks,
Maxwell

 6 
 on: December 03, 2019, 04:13:26 PM 
Started by mc68000 - Last Post by Jaholmes
Hey there, mc68000 - Fellow retro computer engineering hobbyist here. :)  I don't have any schematics to share, but I have a few comments:  First off, the FT245 is a 5V-capable device.  Supply 5V to VCC and VCCIO.  No level translation needed.  Regardless of interrupts, you'll still want a way to poll the FT245 for status, as sending a block of data with interrupts between every byte would be horrendous, performance-wise.  So, map the TXE# and RXF# using a tri-state buffer at some other memory location.  You may have other peripherals with similar needs, so you can probably find things to do with the remaining bits.  /DTACK is a larger topic, but if you're using all reasonably fast peripherals and memories you might get away with simply tying /DTACK to ground, as many others have done in simplistic designs.

If your memory map and selection of peripherals are complex, however, you might bite the bullet and throw a cheap PLD into the mix.  A little will go a long way.  I recently did a 6502 build and fit all the address decoding into a $1.50 22V10 chip.  They're still available from Digikey, and you earn extra 'retro' bonus points by programming them in the ancient CUPL language. ;)

 7 
 on: December 02, 2019, 05:31:45 PM 
Started by Jaholmes - Last Post by Jaholmes
I'm building a USB sensor application using discrete logic--no MCU or CPU.  I have a few candidate designs drawn up, and noticed that I could simplify things if it was permissible to keep WR normally high, then pulse low-high to write.  Datasheets for the FT240X and FT245 are a bit ambiguous about this.  I should mention that I'm also reading bytes, so RD must also being pulsed low-high periodically.  Can this happen while WR is held high--without anything bad happening?  Or must WR be low to read?  I'd guess it would be ok, but figure I ought to put it out there just in case.

Very best,
Aaron

 8 
 on: November 29, 2019, 03:32:10 PM 
Started by asusrog - Last Post by FTDI Community
Hello,

There is nothing in particular with FT230X (vs FT232R) which would cause this issue.
So there must be some issue with your custom PCB.

CTS/RTS flow control signals are used to avoid data loss at high speeds but would probably not avoid data corruption like you are seeing.
Have you wired them up as a test case anyway?

Best Regards,
FTDI Community

 9 
 on: November 29, 2019, 01:00:49 PM 
Started by HASHI4423 - Last Post by HASHI4423
Hi, I am designing a board using FT232HL.

I wanted to use the SPI function, so I connected the EEPROM with reference to the data sheet.

In the reference circuit, it can be read that pull-up resistors on the EECS and EECLK pins are not implemented.
(N.F. = Not Fill ??)

In general, we believe that a pull-up resistor is necessary for level stability of CS.

Is there any reason not to connect?

(Is it pulled up internally?)

 10 
 on: November 28, 2019, 02:26:41 PM 
Started by G40 - Last Post by brenex
Hello,

This issue is caused by other HID class devices connected to the PC.
Did you try disconnecting everything (apart from mouse/keyboard)?

I have a beta for you to try to resolve the issue:

FT_Prog_v0.0.94.440 Installer.zip

Can you please test this out and give us any feedback?

Thanks,
FTDI Community

This fixed the issue for me on Windows 10 64bit

Pages: [1] 2 3 ... 10