unnecessary delay due to excessive buffer purging in raw_read

[GoogleCodeExporter]

What steps will reproduce the problem?
1. read data using raw_read() or Read() or Transfer()

What is the expected output? What do you see instead?
Fast response.  Delayed response.

What version of the product are you using? On what operating system?
libmpsse 1.2 Mac OS X

Please provide any additional information below.

        /* Make sure the buffers are cleared after a read or subsequent reads may fail */
        ftdi_usb_purge_rx_buffer(&mpsse->ftdi);
        ftdi_usb_purge_tx_buffer(&mpsse->ftdi);
        ftdi_usb_purge_buffers(&mpsse->ftdi);

ftdi_usb_purge_buffers already clears both of the buffers by calling 
ftdi_usb_purge_rx_buffer and ftdi_usb_purge_tx_buffer.  In my use of libmpsse 
using SPI, a purge buffer command is not even needed at all.

Original issue reported on code.google.com by epooc...@gmail.com on 31 Jan 2013 at 5:43

[GoogleCodeExporter]

The ftdi_usb_purge_tx_buffer and ftdi_usb_purge_buffers were added when 
troubleshooting issues with the Transfer function, are certainly unnecessary, 
and have been removed.

The ftdi_usb_purge_rx_buffer was originally necessary, although my initial 
testing agrees with your assessment that SPI reads seem to work fine without it 
and my code comments are woefully inadequate to determine if it can be safely 
removed. 

Until further testing can be done, by default ftdi_usb_purge_rx_buffer will be 
called each time raw_read is called, but I've made this a configurable option. 
You can disable the buffer purge by calling FlushAfterRead(0).

Original comment by heffne...@gmail.com on 31 Jan 2013 at 3:50

• Changed state: Started

[GoogleCodeExporter]

After testing, both SPI and I2C function properly with flushing disabled; this 
is now the default. It can be re-enabled if desired by calling 
FlushAfterRead(1).

Original comment by heffne...@gmail.com on 22 Mar 2013 at 4:28

• Changed state: Fixed