'Re: [Rxtx] RXTX and FTDI chips'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rxtx
Subject:    Re: [Rxtx] RXTX and FTDI chips
From:       Curtis Hacker <hakcenter () gmail ! com>
Date:       2010-03-13 2:16:43
Message-ID: 4B9AF58B.1060101 () gmail ! com
[Download RAW message or body]

[Attachment #2 (text/html)]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Helvetica, Arial, sans-serif">Yeah unfortunately if your
using VCP your not going to be able to use the d2xx stuff, and it is up
to the driver installation as to the timer.<br>
<br>
One thing I'm not certain of, is other operating systems, linux has a
configuration file, but I'm not aware if you can set the timer in it.
However windows you can change the inf, or change the settings in
registry yes.<br>
<br>
I can atest to JNA working across ALL operating systems, when the end
user has a proper installation of the driver. Windows, you can just
leave the ftd2xx.dll / ftd2xx64.dll in the working directory of the
java app, however with linux / osx the user has to 'go by the book' for
installing the library properly.<br>
<br>
I use d2xx in my application (car eeprom emulator) and it is extremely
fast in comparison to vcp, no offense to the authors of rxtx. My app
does a bulk upload of 32kb in one shot, seamlessly.<br>
<br>
The only thing I haven't been able to properly use from the d2xx driver
through JNA is the event notifications (rx que) but polling doesn't
seem to bother me much.<br>
</font><br>
On 3/11/2010 10:42 PM, Kustaa Nyholm wrote:
<blockquote cite="mid:C7BFAEEB.D7F7%25kustaa.nyholm@planmeca.com"
 type="cite">
  <pre wrap="">
  </pre>
  <blockquote type="cite">
    <pre wrap="">What your looking for is FT_GetLatencyTimer / FT_SetLatencyTimer, 0 \
- 255 byte.

Quote : d2xx progamming pdf :
"In the FT8U232AM and FT8U245AM devices, the receive buffer timeout that is
used to flush
remaining data from the receive buffer was fixed at 16 ms. In all other FTDI
devices, this timeout is
programmable and can be set at 1 ms intervals between 2ms and 255 ms. This
allows the device
to be better optimized for protocols requiring faster response times from
short data packets."
    </pre>
  </blockquote>
  <pre wrap="">Hi

thanks for posting, this is very interesting information, it appears that
the FTDI support engineer that I talked to was probably right, ie my
dongle has a chip where the flush timeout is fixed.

Good to know that there are devices where you can set the timeout,
although 2 ms can still degrade a protocol performance at high baudrates,
on the other hand, I suppose that a non-high speed USB serial port dongle
has an inherent limitation on how fast you can do a send/receive round trip
because of the inherent 1 ms polling period.

Using FT_SetLatencyTimer requires the use of JNA/JNI which has
some cross platform and installation/packaging implications where as
opening a serial port with Javacomm/RXTX, almost just works out of
the package.

I'm not sure if to be able to use FT_SetLatencyTimer needs the FTDI
drivers (I suppose so), whereas I would expect the some dongles
(maybe not the FTDI?) to work with the built in drivers of the OS?

All good information, thanks for sharing.

br Kusti

_______________________________________________
Rxtx mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rxtx@qbang.org">Rxtx@qbang.org</a>
<a class="moz-txt-link-freetext" \
href="http://mailman.qbang.org/mailman/listinfo/rxtx">http://mailman.qbang.org/mailman/listinfo/rxtx</a>

  </pre>
</blockquote>
</body>
</html>

_______________________________________________
Rxtx mailing list
Rxtx@qbang.org
http://mailman.qbang.org/mailman/listinfo/rxtx

[prev in list] [next in list] [prev in thread] [next in thread] 