Vojtech Michalek wrote:
> Thanks for the tip, I tried it, but it was not the cause. I have performed
> additional transfers totalling several tens of GB and have not realize the
> cause. With respect to low error rate, it is hard to avouch what it
> influences; however, it seems it is dependent on how the output of reading
> program (both "cat" and a program based on libftdi) is handled, i.e., if it
> is just redirected to a file, or pipelined and duplicated with tee to an
> output file and a data check program. For now, I suppose the missing blocks
> may be caused just by USB and Linux "non-realtimeness".
The chip has a 4kB buffer, so writing at 300kBps means you'll run into
problems if something stalls for as little as 13ms. Make sure you're
paying attention to signals like TXE# and not writing to the chip when
its internal buffers are full; that can easily cause lost or corrupted
data.
-jim
> On Fri, Apr 5, 2013 at 7:27 PM, Jim Paris <jim@xxxxxxxx> wrote:
>
> > It seems strange that both libftdi and the kernel driver would have
> > the same problem. Maybe try plugging in the device and going through
> > the Linux driver without running any libftdi code first, just in case
> > libftdi itself is configuring the device in a way that causes
> > problems.
> >
> > -jim
> >
> > Vojtech Michalek wrote:
> > > In order to try to get additional information on the errors origin, I
> > > decided to replace libftdi programs with an alternative ones using
> > > proprietary ftd2xx library. I did not expect any significant change, but
> > it
> > > has transferred more than 4GB without any error so far.
> > >
> > > Vojta
> > >
> > >
> > > On Thu, Apr 4, 2013 at 5:26 PM, Vojtech Michalek <vojtechuv@xxxxxxxxx
> > >wrote:
> > >
> > > > Hi all,
> > > >
> > > > during my measurements, I encounter rare errors in data stream (i.e.,
> > > > approx 10 errors in 1GB data). I use FT2232H in standard asynchronous
> > > > serial mode at 3MBd, transmitting approx. 300kBps. I try to debug it
> > while
> > > > sending incrementing 16bit number in a loop, so that I could check what
> > > > happens with data. From time to time a data block of various size is
> > > > missing.
> > > >
> > > > The same behaviour is reproducible with two topologies:
> > > > 1) transmitter: LPC1343 microcontroller, receiver: FT2232H
> > > > 2) transmitter: FT2232H, receiver: another FT2232H
> > > >
> > > > In order to exclude I do something wrong with libftdi, I try to read
> > the
> > > > data from FT2232 with linux command "cat" (and write with system
> > command
> > > > write for the second topology). I got similar error rate as with
> > libftdi
> > > > functions but with an additional strange effect. Two zero bytes are
> > stuffed
> > > > in the data stream with the following "structure": single zero byte,
> > after
> > > > next correct 511 bytes comes second zero byte, and after next correct
> > 3587
> > > > bytes (really strange number to me) is the missing block of data. Then
> > > > several hundreds of MB of correct data follows before next error
> > occurs.
> > > >
> > > > Have you any hint what I could try to make the communication more
> > reliable?
> > > >
> > > > Thanks,
> > > > Vojta
> > > >
> > >
> > >
> > > --
> > > libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
> > > To unsubscribe send a mail to
> > libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> >
> > --
> > libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
> > To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> >
> >
>
>
> --
> libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
> To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
