Hello Chris,
Last year I had a go at an FTDI device (FT245BM - not the 232
device), and on Windows they behaved as expected. on Mac OSX I found
that a verbose client (>100kbps) which talked into a serial
application with an open port but which did not empty the buffer (no
serial1.readAll) would reliably fail. To be precise, the OS buffer
would lose chunks, and *fail* to signal to the USB device that it
should assert *TXF (i.e. that the transmit buffer is full). The same
hardware worked correctly on Windows XP using a Win32 build of the
same application; and the same issue was present in Zterm on Mac OS X.
At the time, I was using 10.3 (Panther) and the previous
iteration of the FTDI driver (2.1.0). A new driver has come out,
along with a dylib instead of the virtual com port, so I should
resurrect the application and the hardware and see if it all works now.
Note this is applicable only to the FT245BM ... the 232 device
was not tested, and others have indicated no such issues. I also
should say that Keith Dingwall from FTDI has been a very helpful chap
in regard to hardware, and I think they are a good shop to deal with.
Regards,
Tony Barry
On 11/03/2007, at 3:47 AM, Chris Smolinski wrote:
> FWIW, I've had great luck with FTDI chipset based USB/serial
> adapters. Each one has a unique serial number, so there seem to be
> fewer issues with plugging in multiple devices. Might be something to
> think about if you need to supply USB/serial adapters as part of a
> product. They have Mac and Windows drivers, and the lunix drivers are
> built in as of some time ago.
>
> --
>
> ---
> Chris Smolinski
> Black Cat Systems
> http://www.blackcatsystems.com
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>