libftdi Archives

Subject: Re: Purging receive buffer after using BITMODE_BITBANG

From: Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Cc: Colin Bourassa <colin.bourassa@xxxxxxxxx>
Date: Tue, 29 Aug 2023 16:50:37 +0200
Hi Colin,

You wrote on Fri, Mar 31, 2023 at 10:10:28AM -0400:
> Using libftdi 1.5 with an FT232BL, I've run into a situation in which
> bit-bang mode causes the device to fill some internal receive buffer with
> unwanted data that apparently cannot be purged using the normal buffer
> flush routines.
> 
> My use case requires that one of the pins on the FT232 be used in async
> 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 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.
> What can I do to purge only the bit-bang receive data after returning to
> serial mode? Is there a way to prevent it from being buffered in the first
> place?

I don't think there's a reliable way to do this switching
without some "synchronization point" inside the data itself.

In bitbang mode, the chip continuously samples the pins and fills
up the internal read buffer on the chip with that.

ftdi_tciflush() resets the buffer on the chip and also
the libftdi's internal "read buffer offset",
so it's not stale data inside libftdi, it's from the chip.

Which is kind of strange since ftdi_tciflush() really should
make sure the buffer is empty concerning the bitbang related data.

I can't think of a further explanation for now.

Cheers,
Thomas

--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread