0

Using libftdi 1.5 with an FTDI FT232 USB serial converter, I've run into a situation in which bit-bang mode causes the device to fill some internal receive buffer with unwanted data that cannot be purged using the normal buffer flush routines.

My use case requires that one of the pins on the FT232 be used in bit-bang mode (BITMODE_BITBANG) for a couple seconds, and then promptly return to serial/FIFO mode to read data that the remote side will begin sending. The problem: after returning to normal serial mode, calls to ftdi_read_data() will return immediately, reading bytes with the value 0xFC or 0xFF (which I'm guessing represent the bit-bang pin state.) Only after reading 256 bytes like this will the ftdi_read_data() begin to return bytes that actually arrived on the serial lines. The number of 0xFC/0xFF bytes in the buffer seems to correspond to the amount of time spent in bit-bang mode, but it fills quickly -- the entire 256-byte buffer will be filled in a matter of a few milliseconds.

Calling ftdi_tciflush() after leaving bit-bang mode does not appear to have any effect; ftdi_read_data() will still return the unwanted data first.

Is this an expected behavior of the FTDI part, or an idiosyncrasy of libftdi? Other than timing the arrival of bytes in the receive buffer, how is the user meant to distinguish the bit-bang-related bytes from the serial port bytes?

Colin
  • 79
  • 1
  • 7
  • could you explain why bitbanging is required - because maybe there is way to stick to one mode only? The devices are commonly used only in one mode afaik and not switched on the fly. – Christian B. Mar 31 '23 at 18:52
  • Bitbanging is required because the initial communication is done at 5 baud -- well below the range of the baud rate generator. This "slow init" sequence triggers the remote device to wake up and begin communicating at either 4800 or 9600 bps, so the FTDI device must be ready to receive in normal serial port mode at that point. – Colin Mar 31 '23 at 19:04
  • TBH I am not sure if this a quirk of the driver. Maybe one need to wait some time before flushing the buffers. However, I am thinking about a HW based workaround. This would require changing the connections AND it would be ugly - whould this be an option for you? – Christian B. Mar 31 '23 at 19:58
  • HW changes are not an option. The SW needs to use the FT232 device as-is. However, my application may simply allow reading from the receive buffer until a certain sequence of bytes is seen *or* a timeout is met, so I might just take this approach (reading and discarding the junk data.) – Colin Apr 03 '23 at 11:20
  • What is the time delay between wakeup and transmission? Would reopening the device be an option? – Christian B. Apr 03 '23 at 18:03

0 Answers0