Release 0.15 and the ft2232 data loss.

[David Challis]

We use the FT2232H to transfer large amounts of data (megabytes) between a
camera and a Linux host (Fedora 10). We've used release libftdi 0.12 with
the ft245BL without problems. We recently upgraded tolibftdi 0.15 and
started using the high speed mode of the FT2232H. While reading on the host
pc data coming from the ft2232H, we find the we lose some of the data. It
looks like a data overrun or dropped data.



We saw a similar problem with the ftdi supplied D2XX windows drivers. It
turns out that with the windows drivers, we have to turn on rts/cts flow
control to stop the inbound overrun (even though we are running the parallel
interface ft245, where there are no rts/cts lines on the device side(!)).
The FT2232H works fine with windows with this setting.



We've tried using that trick with libftdi to no avail. Is there some sort
of setting or protocol to properly throttle the ft2232H inbound when the
host can't keep up? Has anyone else experienced inbound data loss with
libftdi and the ft2232? Any ideas on where to look next? Could this be an
issue with libusb?



Thanks,



Dave Challis





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

[Matthias Janke]

Hi,

It looks like a data overrun
or dropped data.

I had a similar Problem with a FT232 in serial mode with RTS/CTS
(further details see
http://developer.intra2net.com/mailarchive/html/libftdi/2009/msg00002.html)
To me it seems that libftdi somehow filters CR on inbound. Due to time
restrictions we switched to D2XX driver, which does not have this
problem, so i didn't investigate any further. It also seems that
running the same program(open/write/close) more than once seems to
eat the first char (in our case a #) resetting the bus (replug device)
does fix this.

Any ideas on where to look
next?

I'd sugest somwhere in the reciving part. It might be in device
initalisation part, since CR is the default XON/XOFF char.

Could this be an issue with libusb?

I don't think so since D2XX and libftdi use the same libusb and the
problem occures only with libftdi.

Cheers,
Matthias


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

[David Challis]

Matthias,

We don't run XON/XOFF flow control, as our data stream are binary. That's
why I tried rts/cts and dtr/dsr.

In our case the data loss is inconsistent, that is, it is not the same
character every time and looses several characters each time. Therefore I
don't think this is the library filtering certain characters.

(off topic)
I'd hate to have to switch back to the ftdi supplied D2XX drivers, but that
may be the only solution. The readme for those drivers mention an required
bus reset on device insertion, cause an interruption of data to other
devices. Do you know if this corrupts the data transfer, or just delays it
somewhat?

Thanks.

Dave

-----Original Message-----
Sent: Friday, March 20, 2009 2:39 AM
Subject: Re: Release 0.15 and the ft2232 data loss.
Hi,

It looks like a data overrun
or dropped data.

I had a similar Problem with a FT232 in serial mode with RTS/CTS
(further details see
http://developer.intra2net.com/mailarchive/html/libftdi/2009/msg00002.h
tml)
To me it seems that libftdi somehow filters CR on inbound. Due to time
restrictions we switched to D2XX driver, which does not have this
problem, so i didn't investigate any further. It also seems that
running the same program(open/write/close) more than once seems to
eat the first char (in our case a #) resetting the bus (replug device)
does fix this.

Any ideas on where to look
next?

I'd sugest somwhere in the reciving part. It might be in device
initalisation part, since CR is the default XON/XOFF char.

Could this be an issue with libusb?

I don't think so since D2XX and libftdi use the same libusb and the
problem occures only with libftdi.
Cheers,
Matthias
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to

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

[Thomas Jarosch]

Hi Dave,

Post by David Challis
We use the FT2232H to transfer large amounts of data (megabytes) between a
camera and a Linux host (Fedora 10). We've used release libftdi 0.12 with
the ft245BL without problems. We recently upgraded tolibftdi 0.15 and
started using the high speed mode of the FT2232H. While reading on the
host pc data coming from the ft2232H, we find the we lose some of the data.
It looks like a data overrun or dropped data.

Does the problem go away when you downgrade again to libftdi 0.12?

Cheers,
Thomas


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

[David Challis]

I'll work on a downgraded test this afternoon and will advise on the results
tomorrow.

Cheers,

Dave

-----Original Message-----
Sent: Friday, March 20, 2009 2:42 AM
Subject: Re: Release 0.15 and the ft2232 data loss.
Hi Dave,

Post by David Challis
We use the FT2232H to transfer large amounts of data (megabytes)

between a

Post by David Challis
camera and a Linux host (Fedora 10). We've used release libftdi 0.12

with

Post by David Challis
the ft245BL without problems. We recently upgraded tolibftdi 0.15

and

Post by David Challis
started using the high speed mode of the FT2232H. While reading on

the

Post by David Challis
host pc data coming from the ft2232H, we find the we lose some of the

data.

Post by David Challis
It looks like a data overrun or dropped data.

Does the problem go away when you downgrade again to libftdi 0.12?
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to

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

[David Challis]

Thomas,

I tried release 0.9 with similar results. The problem does not go away.

Cheers,
Dave Challis

-----Original Message-----
Sent: Friday, March 20, 2009 2:42 AM
Subject: Re: Release 0.15 and the ft2232 data loss.
Hi Dave,

Post by David Challis
We use the FT2232H to transfer large amounts of data (megabytes)

between a

Post by David Challis
camera and a Linux host (Fedora 10). We've used release libftdi 0.12

with

Post by David Challis
the ft245BL without problems. We recently upgraded tolibftdi 0.15

and

Post by David Challis
started using the high speed mode of the FT2232H. While reading on

the

Post by David Challis
host pc data coming from the ft2232H, we find the we lose some of the

data.

Post by David Challis
It looks like a data overrun or dropped data.

Does the problem go away when you downgrade again to libftdi 0.12?
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to

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

[David Challis]

More interesting data. The read that fails (requesting 102 bytes), always
comes up 2 bytes short.



The sequence is this: Two bytes are send to the camera to initial a request.
The camera returns 104 bytes. The host first reads 2 bytes in a read call,
then the remaining 102 bytes in a second read call.



When running the test case, I put a break point in ftdi_read_data,
"num_of_chunks = ret / 64; See below. The break point is hit on the first
read call of two bytes requested.



When stopped at the break point, the value of "ret" is 104! Just like there
are no modem status bytes in the data stream! I would expect 2 + 104 or 106
bytes at that point in the code-two bytes of modem status, then the 104
bytes of camera data.



Has the ft2232H ever been tested with libftdi in async FIFO mode? Does the
ft2232H not send modem status bytes in that configuration?



Any other ideas?



Thanks,



Dave Challis





int ftdi_read_data(struct ftdi_context *ftdi, unsigned char *buf, int size)

{

int offset = 0, ret = 1, i, num_of_chunks, chunk_remains;



// everything we want is still in the readbuffer?

if (size <= ftdi->readbuffer_remaining) {

memcpy (buf, ftdi->readbuffer+ftdi->readbuffer_offset, size);



// Fix offsets

ftdi->readbuffer_remaining -= size;

ftdi->readbuffer_offset += size;



/* printf("Returning bytes from buffer: %d - remaining: %d\n", size,
ftdi->readbuffer_remaining); */



return size;

}

// something still in the readbuffer, but not enough to satisfy 'size'?

if (ftdi->readbuffer_remaining != 0) {

memcpy (buf, ftdi->readbuffer+ftdi->readbuffer_offset,
ftdi->readbuffer_remaining);



// Fix offset

offset += ftdi->readbuffer_remaining;

}

// do the actual USB read

while (offset < size && ret > 0) {

ftdi->readbuffer_remaining = 0;

ftdi->readbuffer_offset = 0;

/* returns how much received */

ret = usb_bulk_read (ftdi->usb_dev, ftdi->out_ep, ftdi->readbuffer,
ftdi->readbuffer_chunksize, ftdi->usb_read_timeout);

if (ret < 0)

ftdi_error_return(ret, "usb bulk read failed");



if (ret > 2) {

// skip FTDI status bytes.

// Maybe stored in the future to enable modem use

num_of_chunks = ret / 64;

chunk_remains = ret % 64;

//printf("ret = %X, num_of_chunks = %X, chunk_remains = %X,
readbuffer_offset = %X\n", ret, num_of_chunks, chunk_remains,
ftdi->readbuffer_offset);



ftdi->readbuffer_offset += 2;

ret -= 2;



if (ret > 62) {

for (i = 1; i < num_of_chunks; i++)

memmove (ftdi->readbuffer+ftdi->readbuffer_offset+62*i,

ftdi->readbuffer+ftdi->readbuffer_offset+64*i,

62);

if (chunk_remains > 2) {

memmove (ftdi->readbuffer+ftdi->readbuffer_offset+62*i,

ftdi->readbuffer+ftdi->readbuffer_offset+64*i,

chunk_remains-2);

ret -= 2*num_of_chunks;

} else

ret -= 2*(num_of_chunks-1)+chunk_remains;

}

} else if (ret <= 2) {

// no more data to read?

return offset;

}

if (ret > 0) {

// data still fits in buf?

if (offset+ret <= size) {

memcpy (buf+offset,
ftdi->readbuffer+ftdi->readbuffer_offset, ret);

//printf("buf[0] = %X, buf[1] = %X\n", buf[0], buf[1]);

offset += ret;



/* Did we read exactly the right amount of bytes? */

if (offset == size)

//printf("read_data exact rem %d offset %d\n",

//ftdi->readbuffer_remaining, offset);

return offset;

} else {

// only copy part of the data or size <=
readbuffer_chunksize

int part_size = size-offset;

memcpy (buf+offset,
ftdi->readbuffer+ftdi->readbuffer_offset, part_size);



ftdi->readbuffer_offset += part_size;

ftdi->readbuffer_remaining = ret-part_size;

offset += part_size;



/* printf("Returning part: %d - size: %d - offset: %d - ret:
%d - remaining: %d\n",

part_size, size, offset, ret, ftdi->readbuffer_remaining);
*/



return offset;

}

}

}

// never reached

return -127;

}



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

[David Challis]

Ok, I think I understand more about what is going on. In the
ftdi_read_data() function:



if (ret > 2) {

// skip FTDI status bytes.

// Maybe stored in the future to enable modem use

num_of_chunks = ret / 64;

chunk_remains = ret % 64;

//printf("ret = %X, num_of_chunks = %X, chunk_remains = %X,
readbuffer_offset = %X\n", ret, num_of_chunks, chunk_remains,
ftdi->readbuffer_offset);



ftdi->readbuffer_offset += 2;

ret -= 2;



if (ret > 62) {

for (i = 1; i < num_of_chunks; i++)

memmove (ftdi->readbuffer+ftdi->readbuffer_offset+62*i,

ftdi->readbuffer+ftdi->readbuffer_offset+64*i,

62);

if (chunk_remains > 2) {

memmove (ftdi->readbuffer+ftdi->readbuffer_offset+62*i,

ftdi->readbuffer+ftdi->readbuffer_offset+64*i,

chunk_remains-2);

ret -= 2*num_of_chunks;

} else

ret -= 2*(num_of_chunks-1)+chunk_remains;

}

} else if (ret <= 2) {

// no more data to read?

return offset;

}



The code assumes that there will be a modem status byte pair for every 64
bytes returned by the ftdi chip. For the ft245BL, this is true. For the
ft2232H, it appears that the modem status bytes are returned only once per
usb_bulk_read call. Setting a break at "if (ret > 2)", I examine the results
of the bulk_read. There are 106 bytes total. The first two bytes are the
modem status bytes as expected. The remaining 104 bytes are the data sent
from my device, with no additional modem status bytes embedded in the
stream. Thus, as the code stands now, it will delete bytes 65 and 66,
thinking that they are modem status bytes, when in fact they are not.



Could this be the issue? Is there anything else I can do on my end to prove
this out? What would be the suggested fix?



Thanks,



Dave Challis









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

[Uwe Bonnes]

..

David> The code assumes that there will be a modem status byte pair for
David> every 64 bytes returned by the ftdi chip. For the ft245BL, this
David> is true. For the ft2232H, it appears that the modem status bytes
David> are returned only once per usb_bulk_read call. Setting a break at
David> "if (ret > 2)", I examine the results of the bulk_read. There
David> are 106 bytes total. The first two bytes are the modem status
David> bytes as expected. The remaining 104 bytes are the data sent
David> from my device, with no additional modem status bytes embedded in
David> the stream. Thus, as the code stands now, it will delete bytes
David> 65 and 66, thinking that they are modem status bytes, when in
David> fact they are not.

Nice finding.

David> Could this be the issue? Is there anything else I can do on my
David> end to prove this out? What would be the suggested fix?

It seems to be the issue. The fixed "64" in the code above should probably
replaced by a variable set by the MaxPacketSize value of the appropriate
Endpoint descriptor.


David> </html>
Any need to repeat the mail message as HTML?

Bye

[David Challis]

Here is my final answer:

The ft2232H spaces the modem status bytes every 512 bytes rather that the
expected 64 byte interval of prior chips like the ft245. Libftdi will have
to be changed to detect the type of chip connected and adapt the
ftdi_read_data() routine to handle the appropriate spacing between modem
status bytes.

Cheers,

Dave Challis



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

[Thomas Jarosch]

Post by David Challis
The ft2232H spaces the modem status bytes every 512 bytes rather that the
expected 64 byte interval of prior chips like the ft245. Libftdi will have
to be changed to detect the type of chip connected and adapt the
ftdi_read_data() routine to handle the appropriate spacing between modem
status bytes.

Good work! Maybe the attached patch will help you.

Cheers,
Thomas



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

[David Challis]

Post by Thomas Jarosch
Good work! Maybe the attached patch will help you.
Cheers,
Thomas

Thomas,

The line in the patch:

else if (dev->descriptor.bcdDevice == 0x800)
ftdi->type = TYPE_2232H;

for the FT2232H should be:

else if (dev->descriptor.bcdDevice == 0x700)
ftdi->type = TYPE_2232H;


With your patch applied, my proposed new ftdi_read_data() is:

/**
Reads data in chunks (see ftdi_read_data_set_chunksize()) from the chip.

Automatically strips the two modem status bytes transfered during every
read.

\param ftdi pointer to ftdi_context
\param buf Buffer to store data in
\param size Size of the buffer

\retval <0: error code from usb_bulk_read()
\retval 0: no data was available
\retval >0: number of bytes read

\remark This function is not useful in bitbang mode.
Use ftdi_read_pins() to get the current state of the pins.
*/
int ftdi_read_data(struct ftdi_context *ftdi, unsigned char *buf, int size)
{
int offset = 0, ret = 1, i, num_of_chunks, chunk_remains;
int packet_size;

switch (ftdi->type)
{
case TYPE_2232H:
packet_size = 512;
break;
default:
packet_size = 64;
}

// everything we want is still in the readbuffer?
if (size <= ftdi->readbuffer_remaining) {
memcpy (buf, ftdi->readbuffer+ftdi->readbuffer_offset, size);

// Fix offsets
ftdi->readbuffer_remaining -= size;
ftdi->readbuffer_offset += size;

return size;
}
// something still in the readbuffer, but not enough to satisfy 'size'?
if (ftdi->readbuffer_remaining != 0) {
memcpy (buf, ftdi->readbuffer+ftdi->readbuffer_offset,
ftdi->readbuffer_remaining);
// Fix offset
offset += ftdi->readbuffer_remaining;
}
// do the actual USB read
while (offset < size && ret > 0) {
ftdi->readbuffer_remaining = 0;
ftdi->readbuffer_offset = 0;
/* returns how much received */
ret = usb_bulk_read (ftdi->usb_dev, ftdi->out_ep, ftdi->readbuffer,
ftdi->readbuffer_chunksize, ftdi->usb_read_timeout);

if (ret < 0)
ftdi_error_return(ret, "usb bulk read failed\n");

if (ret > 2) {
// skip FTDI status bytes.
// Maybe stored in the future to enable modem use
num_of_chunks = ret / packet_size;
chunk_remains = ret % packet_size;
ftdi->readbuffer_offset += 2;
ret -= 2;

if (ret > packet_size - 2) {
for (i = 1; i < num_of_chunks; i++)
memmove
(ftdi->readbuffer+ftdi->readbuffer_offset+(packet_size - 2)*i,

ftdi->readbuffer+ftdi->readbuffer_offset+packet_size*i, packet_size - 2);
if (chunk_remains > 2) {
memmove
(ftdi->readbuffer+ftdi->readbuffer_offset+(packet_size - 2)*i,

ftdi->readbuffer+ftdi->readbuffer_offset+packet_size*i, chunk_remains-2);
ret -= 2*num_of_chunks;
}
else
ret -= 2*(num_of_chunks-1)+chunk_remains;

}
}
else if (ret <= 2) {
// no more data to read?
return offset;
}

if (ret > 0) {
// data still fits in buf?
if (offset+ret <= size) {
memcpy (buf+offset,
ftdi->readbuffer+ftdi->readbuffer_offset, ret);
offset += ret;

/* Did we read exactly the right amount of bytes? */
if (offset == size) {
//printf("read_data exact readdata->rem %d offset %d\n",
ftdi->readbuffer_remaining, offset);
}
return offset;
}
else {
// only copy part of the data or size <=
readbuffer_chunksize
int part_size = size-offset;
memcpy (buf+offset,
ftdi->readbuffer+ftdi->readbuffer_offset, part_size);

ftdi->readbuffer_offset += part_size;
ftdi->readbuffer_remaining = ret-part_size;
offset += part_size;

return offset;
}
}
}
// never reached
return -127;
}


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

[Uwe Bonnes]

Post by Thomas Jarosch
Good work! Maybe the attached patch will help you.
Cheers, Thomas

David> Thomas,

David> The line in the patch:

David> else if (dev->descriptor.bcdDevice == 0x800)
ftdi-> type = TYPE_2232H;

David> for the FT2232H should be:

David> else if (dev->descriptor.bcdDevice == 0x700)
ftdi-> type = TYPE_2232H;


The 4432h will behave the same.

[Thomas Jarosch]

Post by David Challis
else if (dev->descriptor.bcdDevice == 0x800)
ftdi->type = TYPE_2232H;
else if (dev->descriptor.bcdDevice == 0x700)
ftdi->type = TYPE_2232H;

Ah ok. I did this by looking at the output provided from George Boudreau.
If I understood Uwe Bonnes correctly, this could read:

if (dev->descriptor.bcdDevice == 0x700 || dev->descriptor.bcdDevice == 0x800)

Right?
Please resend as a patch, the line endings got mangled.
Also this will make review of the changes easier. Thanks.

Thomas


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

[George Boudreau]

On Mon, Mar 23, 2009 at 12:20 PM, Thomas Jarosch <

Post by Thomas Jarosch

Post by David Challis
else if (dev->descriptor.bcdDevice == 0x800)
ftdi->type = TYPE_2232H;
else if (dev->descriptor.bcdDevice == 0x700)
ftdi->type = TYPE_2232H;

Ah ok. I did this by looking at the output provided from George Boudreau.

It seems my FT2232H mini/mod may be defective. Although the silkscreen says
FT2232H and the ftdi chip reads FT2232HQ note the output. It reads as a
'Quad RS232' and enumerates 4 USB ports. When I explored this chip module
on a windows machine I received the same results, 4 USB ports.

This output may be appropriate for a FT4232H device but not a FT2232H

Post by Thomas Jarosch
if (dev->descriptor.bcdDevice == 0x700 || dev->descriptor.bcdDevice == 0x800)
Right?
Please resend as a patch, the line endings got mangled.
Also this will make review of the changes easier. Thanks.
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.

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

[David Challis]

Patch file attached for ftdi.c

Post by Thomas Jarosch
if (dev->descriptor.bcdDevice == 0x700 || dev->descriptor.bcdDevice == 0x800)
Right?

I think we need to add a device type for the FT4232H with bcdDevice ==
0x800. Uwe can advise on the appropriate packet size for that device.

Dave


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

[Uwe Bonnes]

David> Patch file attached for ftdi.c

Post by Thomas Jarosch
if (dev->descriptor.bcdDevice == 0x700 || dev->descriptor.bcdDevice == 0x800)
Right?

David> I think we need to add a device type for the FT4232H with
David> bcdDevice == 0x800. Uwe can advise on the appropriate packet
David> size for that device.

I don't have a FT4432H device, so I can't comment on the bcdDevice number.

But the FT4432H is a USB-2.0 High Speed device like the FT2232H, and the
maximum packet size for a high speed device for the bulk endpoints is 512
bytes versus 64 bytes for full speed devices. It wouldn't make sense, if the
FT4432h uses a smaller packer size, as this will hog the USB channel, where
4 serial to usb machines inside the FT4432h wait to pump theier data through
the USB channel.

Bye

[Thomas Jarosch]

Post by David Challis
Patch file attached for ftdi.c

Patch is applied (with minor tweaking):
http://developer.intra2net.com/git/?p=libftdi;a=commit;h=f2f00cb562550c876da2119edeb1dd228aa2abfa

Now we support FT2232H and FT4232H :-)

Thanks,
Thomas


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

[Uwe Bonnes]

David> We use the FT2232H to transfer large amounts of data (megabytes)
David> between a camera and a Linux host (Fedora 10). We've used
David> release libftdi 0.12 with the ft245BL without problems. We
David> recently upgraded tolibftdi 0.15 and started using the high speed
David> mode of the FT2232H. While reading on the host pc data coming
David> from the ft2232H, we find the we lose some of the data. It looks
David> like a data overrun or dropped data.

Dave,

could you please be more verbose?
Information about
- Datarate
- USB Chipset
- CPU
comes to mind.

Bye

[David Challis]

Here is a some more information on my setup.

On the camera side, we have a ft2232H, running a single channel in high
speed async fifo mode. Data rate to the host is 800kbytes per second max.
Data flow from the camera microprocessor to the ft2232H is regulated by the
ft2232H asserting/de-asserting the TXE# pin.

The Linux test host is an eMachines T5224. Dual Core Pentium D 820 2.8 Ghz
with 1 GB ram. Intel 945 / NH82801 chipset. Testing with Fedora 10.
Current libftdi is 0.15. As I said above, this setup works perfectly with
the ft245bl. Switching to the ft2232H causes the data loss.

This setup with the ft2232H works without data loss on Windows and works
with a ft245BL in place of the ft2232H on both Windows and Linux, so we know
the camera interface is correct.

The test case that fails is very simple:

The host opens a connection to the ft2232H. 4 bytes of data are written
from the host to the camera. The camera responds with 128 bytes back to the
host. The host issues two read requests. One for 2 bytes (to get the
packet data size) and then one for the remaining bytes to be sent. The
second read times out and does not receive the entire 128 bytes sent by the
camera.

Looking at the buffer after each failure show that the data loss is not
consistent. The data sent by the camera is an ascii text string in this
case. Each time the test is run, a different part of the text string is
missing.

It feels like that with the high speed transfer, the data from the device is
arriving faster than the host can handle it. I would expect that as the
host falls behind, the #TXE would be de-asserted, stopping the data flow
until the host catches up. I would guess that I'm not configuring the
ft2232H properly.

This is indeed what happens with the windows drivers (with rts/cts flow
control turned on) as a comparison. That is what leads me to believe that
it is something wrong on the Linux host side, rather than a problem with the
ft2232H.

Any ideas or thoughts would be appreciated.

Cheers,

Dave Challis

-----Original Message-----
Sent: Friday, March 20, 2009 2:42 AM
Subject: Re: Release 0.15 and the ft2232 data loss.
David> We use the FT2232H to transfer large amounts of data (megabytes)
David> between a camera and a Linux host (Fedora 10). We've used
David> release libftdi 0.12 with the ft245BL without problems. We
David> recently upgraded tolibftdi 0.15 and started using the high speed
David> mode of the FT2232H. While reading on the host pc data coming
David> from the ft2232H, we find the we lose some of the data. It looks
David> like a data overrun or dropped data.
Dave,
could you please be more verbose?
Information about
- Datarate
- USB Chipset
- CPU
comes to mind.
Bye
--
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to

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

[Uwe Bonnes]

David> Here is a some more information on my setup. On the camera side,
David> we have a ft2232H, running a single channel in high speed async
David> fifo mode. Data rate to the host is 800kbytes per second max.
Any chance to use the synchronous fifi mode?

[David Challis]

Not with the current camera design. The synchronous FIFO mode requires that
the data source sync the writes with the ft2232H clk output. It will
require a logic change to accommodate that. We are working on a future
design that will do this, as the data rate required is much higher, but we'd
like to retrofit the current design with a ft2232H, which means we need to
use the async FIFO mode.

Async FIFO should have plenty of bandwidth (and it works well with windows).

Dave

-----Original Message-----
Sent: Friday, March 20, 2009 4:18 PM
Subject: RE: Release 0.15 and the ft2232 data loss.
David> Here is a some more information on my setup. On the camera side,
David> we have a ft2232H, running a single channel in high speed async
David> fifo mode. Data rate to the host is 800kbytes per second max.
Any chance to use the synchronous fifi mode?
--
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. [phone] -------- Fax. [phone] ----------
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to

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

[Pierre Bouffard]

Does anyone know the spacing of modem status bytes for the FT232BL?

Thank you.

Pierre

-----Original Message-----
From: David Challis [mailto:***@qsimaging.com]
Sent: 22 mars 2009 19:08
To: ***@developer.intra2net.com
Subject: SOLVED: Release 0.15 and the ft2232 data loss.

Here is my final answer:

The ft2232H spaces the modem status bytes every 512 bytes rather that
the
expected 64 byte interval of prior chips like the ft245. Libftdi will
have
to be changed to detect the type of chip connected and adapt the
ftdi_read_data() routine to handle the appropriate spacing between modem
status bytes.

Cheers,

Dave Challis



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


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