|
From: Cory S. <co...@mo...> - 2006-03-30 10:06:25
|
I can get libftdi to work in Cygwin, but also experience issues you describe (read basically fails). I'm using libftdi 0.7 and have tried both libusb-win32 0.1.10.1 and CVS HEAD as of today. libftdi DOES work for me without problem providing I compile libftdi and my application *without* -mno-cygwin. My ftdi/usb reads fail when I compile libftdi and my application with -mno-cygwin. Unfortunately, one of the things I'm building is a JNI DLL to be used by Java -- which pretty much requires -mno-cygwin. I can try to debug this, but I'd appreciate any suggestions about what kinds of things I should be looking for in particular, and where. Thanks, best, Cory ----- On 2006-01-09 03:23, <morper@te...> wrote: Has anyone tried to use libusb-win32 together with libftdi from intra2net? (http://www.intra2net.com/de/produkte/opensource/ftdi/index.php)= . I have the problem that, when I try to read data from the device via libftdi based on libusb-win32, I only receive some single bytes with very high values (between 248 and 255). Using the same software under Linux with libusb works correctly. Thanks for any suggestions. |
|
From: Jonathon <j...@co...> - 2006-04-21 09:47:49
|
How did you go Cory? Did you get libftdi working on libusb-win32 ?? I'm working on a project doing that at the moment. I think I can get it all to build properly, but I'm using Visual C++ J. |
|
From: Cory S. <co...@mo...> - 2006-04-21 22:51:06
|
Hi Jonathon, Yes, I did get libftdi to work. My problems turned out to be related to Cygwin with the -mno-cygwin option. Compiling libusb-win32, libftdi, and my own application and libraries with MinGW/Msys solved the issues I was having. I admit it should not have made a difference, but it did, and I'm glad it now works. I have not tried Visual C++ so cannot provide any helpful hints for that specifically. One thing you should be aware of is that a read in libftdi may return no payload (0 bytes). So, I wrote a wrapper to perform a timed read by continually polling ftdi_read_data until the requested number of bytes were received or the timeout in milliseconds elapsed. You may need to do something similar in your code. Best of luck, Cory On 4/21/06, Jonathon <j...@co...> wrote: > How did you go Cory? > > Did you get libftdi working on libusb-win32 ?? > > I'm working on a project doing that at the moment. I think I can get it > all to build properly, but I'm using Visual C++ > > J. On 3/30/06, Cory Sharp <co...@mo...> wrote: > I can get libftdi to work in Cygwin, but also experience issues you > describe (read basically fails). I'm using libftdi 0.7 and have tried > both libusb-win32 0.1.10.1 and CVS HEAD as of today. > > libftdi DOES work for me without problem providing I compile libftdi > and my application *without* -mno-cygwin. My ftdi/usb reads fail when > I compile libftdi and my application with -mno-cygwin. > > Unfortunately, one of the things I'm building is a JNI DLL to be used > by Java -- which pretty much requires -mno-cygwin. > > I can try to debug this, but I'd appreciate any suggestions about what > kinds of things I should be looking for in particular, and where. > > Thanks, best, > Cory > > ----- On 2006-01-09 03:23, <morper@te...> wrote: > > Has anyone tried to use libusb-win32 together with libftdi from > intra2net? (http://www.intra2net.com/de/produkte/opensource/ftdi/index.ph= p). > > I have the problem that, when I try to read data from the device via > libftdi based on libusb-win32, I only receive some single bytes with > very high values (between 248 and 255). Using the same software under > Linux with libusb works correctly. > > Thanks for any suggestions. |
|
From: Jonathon <j...@co...> - 2006-04-21 23:56:17
|
> One thing you should be aware of is that a read in libftdi may return
> no payload (0 bytes).
Yes, the reason for this is because usb_read_bulk() to an FTDI chip always
returns 2 status bytes in addition to the payload. So usb_read_bulk()
never blocks, always returning 2 status bytes, or 2 status bytes +
payload.
hence, ftdi_read_data never blocks either. (ftdi_read_data obviously
removes the status bytes, leaving you with zero bytes)
I'd already half written my code before I found libftdi, which is how I've
figured out all this stuff.
I was working on making my software 'cope' with the usb being unplugged,
and being plugged in again. (Software says... you've gone offline, then
says you've gone back online)
Rather interestingly, subsequent calls to usb_claim_interface() ... (or
the libftdi equivalent) when claiming it for a second time [after
unplugging and replugging] would always fail. ('The device is busy') ...
but if I set the latency setting (16ms by default [in the chip]) somewhere
in my code (even to 16ms, which it was already set to!), claiming the
interface a second time would succeed.
oh, man, there's way too much magic in these FTDI chips.
> by continually polling ftdi_read_data until the requested number of
> bytes were received or the timeout in milliseconds elapsed.
yeah, did the same thing.
cheers
Jonathon
|
|
From: Jonathon L. - H. <jon...@ha...> - 2006-04-24 00:37:18
|
Cory, Do you have libftdi and libusb-win32 packaged in the same dll? I'd like to put them in the same dll, but I'd rather avoid figuring out all the cygwin stuff. (So could I have a copy of yours?) Does mingw generate .lib files that VC++ can use? with thanks Jonathon Love |
|
From: Cory S. <co...@mo...> - 2006-04-24 20:26:33
|
On 4/23/06, Jonathon Love - Haltech <jon...@ha...> wrote: > Cory, > > Do you have libftdi and libusb-win32 packaged in the same dll? I have not put them together in a DLL as a Windows driver because there is no need. I have a number of application specific exe's as well as an application specific DLL exposing a JNI interface -- all statically linked with libusb and libftdi. > I'd like to put them in the same dll, but I'd rather avoid figuring out > all the cygwin stuff. (So could I have a copy of yours?) > > Does mingw generate .lib files that VC++ can use? No, it doesn't. Though, I don't use VC++, so I don't really know how it may / may not interoperate with object files and libraries built with in MinGW with GCC. Best, Cory |