On Friday, 21 Mar 2017 18:23:38 +0200, Thomas Jarosch
<thomas.jarosch@xxxxxxxxxxxxx> wrote
> thanks for your patch! Some questions below.
>
> On Monday, 10 April 2017 15:54:15 CEST Eric Schott wrote:
>> The provided patch is at the user's risk.
>> No licensing of this patch can preclude its use by the governement of
>> the United States or The Applied Research Laboratory of The
>> Pennsylvania State University.
>
> would you be ok with licensing the purge_test.c code
> as GPL v2 like the other example codes?
>
> That would still fulfill your "license requirement" above.
Yes. This is fine. I included text as directed by my supervisor. The
GPL is a difficult concept.
> Perhaps it's a good idea to split the purge fix,
> the new example code and the C++ fixes into three (logical) commits.
I will do that.
>> diff --git a/src/ftdi.h b/src/ftdi.h
>> index bb66c53..acc1869 100644
>> --- a/src/ftdi.h
>> +++ b/src/ftdi.h
>> @@ -173,8 +173,8 @@ enum ftdi_module_detach_mode
>>
>>
>> #define SIO_RESET_SIO 0
>> -#define SIO_RESET_PURGE_RX 1
>> -#define SIO_RESET_PURGE_TX 2
>> +#define SIO_RESET_PURGE_TX 1
>> +#define SIO_RESET_PURGE_RX 2
>
>
> this change puzzles me. I've searched for my original USB "API documentation"
> received under NDA in 2003 and it specifies these control values:
> 0: Reset SIO
> 1: Purge RX buffer
> 2: Purge TX buffer.
I suspected you would be puzzled by the changes. I do not have
access to the NDA.
My desire was to as closely emulate the standard behavior of
the Linux serial port behavior of the ftdi_sio driver with respect
to purge (tcflush) and tcdrain functions. This is difficult based upon
the libftdi's different architecture (more on this shortly).
With the devices we control (e.g., GPS) consistent behavior is
important when needing to change baud rate or wait until all
data has been transmitted.
First, my observations of the Linux kernel with ftdi_sio driver
1. ftdi_sio never uses the SIO_RESET_PURGE definitions.
2. The kernel behavior for write: buffer the data and return
immediately. The driver outputs the buffered data in
background.
3. The kernel behavior for read is to always read data and
store into an internal buffer. The data is returned
immediately to the user application with the read.
The test program (with a loopback) does
* A write of a block of data
* A delay for 1/2 of the anticipated transmit interval
* Issue one of the three flush calls (read, write and both)
* Do a drain function for the remainder of the data to be
transmitted.
* Call the read function to obtain any buffered received data.
The Linux kernel behavior with all chips is
1 Read flush:
* The first 1/2 of the data is discarded (which was received)
* The drain function waits the remaining output data has been
sent out of the hardware.
* The read returns the second half of the data
2 Write flush:
* The second have the data (in kernel buffers) is discarded
* The drain returns immediately (since there is no data do
send)
* The read returns the first half of the data.
3 Read & Write flush
* The first half of the data (already buffered) is discarded
* The buffered output data is flushed
* The drain returns effectively immediately
* The read returns a handful of characters in the middle
of the message.
When using the Linux drivers, I have observed this (expected) behavior
with the test program with for the following
* 16550 UART (which has shallow hardware buffers)
* FT232 (which appears to have shallow hardware buffers)
* FT4232 (which has deep hardware buffers).
Returning to the promised discussion of libftdi's implementation
architecture: it basically does not have the background processing
as does the kernel. The standard read, write, and flush all
effectively perform hardware I/O via libusb. (This is somewhat of
a simplification. Please excuse me if I have some incorrectly
represented the library).
My observations with libftdi the FT4232 before swapping TX and RX
purge definitions was the read flush exhibited behavior of the Linux
write flush and the write flush exhibited the behavior of the
read flush. I found it difficult to characterize the behavior on
the FT232 chip.
> Did you run your tests only with the FT4232 type chips?
I performed tests on the hardware I had available (16650, FT232,
and FT4232). Obviously I could not use libftdi for the 16650.
> Also you mention the purge doesn't work correctly,
> even after fixing it?
I was referring to the the FT232 chip only. The FT4232's deep
FIFOs make libftdi's purge functions work correctly
> I guess there's an equivalent purge function in D2XX,
> it might make sense to take a look either at the sent USB URBs
> or I might even disassemble the purge function of it.
> (which is legal in Germany as long as it's to ensure compatibility)
I do not have the luxury of this. Please do as you see fit.
That includes being free to discard this patch if you feel it is not
in the community's best interest. I will not be offended. I will
continue to apply my patch. My desire in submitting the patch was to
aid other developers when they may encounter similar issues.
It will be short time before I rearrange the patches.
Best regards.
Eric.
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
