libftdi (usb-to-ftdi chip) discussion list ()

Spindler, Tyler L | 19 Apr 2012 17:47

libftdi 0.x thread recommendations

I have written a program using bit bang mode for the libftdi library. It has 2 threads. One runs all the time
and reads data using ftdi_read_data function call. The second thread, based on program logic, will
occasionally call ftdi_write_data.

This has worked reasonable well. However, after many, many months of run time, I have experienced the
communication to the chipset fail on a ftdi_write_data call. When it does occur, all interaction with the
libftdi library to fails. dmesg reports this each time the application tries to interact with the library:

usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd cProtocolGatewa rqt 64 rq 0 len 0 ret -145

The only resolve has been to unplug the USB device and bounce the kernel modules or reboot the system. This is
not desirable.

Is there a way to prevent this error? Am I violating the rules since I have read that libusb 0.1 / libftdi 0.x
are not thread safe? Any recommendations on different techniques / function calls to use inside the 2
threads? I'd prefer to continue to use the 0.x version of the library.

Let me know if you need any additional information. Any help would be appreciated. Thanks!

Tyler

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

headers

Thomas Jarosch | 24 Apr 2012 08:24

Re: libftdi 0.x thread recommendations

Hi Tyler,

On Thursday, 19. April 2012 17:47:59 Spindler, Tyler L wrote:

> Is there a way to prevent this error? Am I violating the rules since I

> have read that libusb 0.1 / libftdi 0.x are not thread safe? Any

> recommendations on different techniques / function calls to use inside

> the 2 threads? I'd prefer to continue to use the 0.x version of the

> library.

libftdi is not designed to be thread safe.

Do you use proper locking before calling into libftdi?

Thomas

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

headers

Spindler, Tyler L | 24 Apr 2012 16:26

RE: libftdi 0.x thread recommendations

>> Is there a way to prevent this error? Am I violating the rules since I

>> have read that libusb 0.1 / libftdi 0.x are not thread safe? Any

>> recommendations on different techniques / function calls to use inside

>> the 2 threads? I'd prefer to continue to use the 0.x version of the

>> library.

> libftdi is not designed to be thread safe.

> Do you use proper locking before calling into libftdi?

> Thomas

I just added mutex locking and unlocking to my program’s code base. All the interactions with the libftdi library will now be protected. Thanks for the feedback.

Tyler

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

headers

Thomas Heller | 24 Apr 2012 16:46

Re: libftdi 0.x thread recommendations

Am 24.04.2012 08:24, schrieb Thomas Jarosch:
> libftdi is not designed to be thread safe.

But libusb-win32 is threadsafe? According to
http://libusb.6.n5.nabble.com/Thread-safety-and-driver-file-name-td3278420.html

So, if I patch the libftdi-calls that I use to do locking
then I am safe?

I want to read and write at the same time in different threads
from/to a FT2232H chip...

Thomas

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

headers

Thomas Jarosch | 25 Apr 2012 09:29

Re: libftdi 0.x thread recommendations

On Tuesday, 24. April 2012 16:46:45 Thomas Heller wrote:
> Am 24.04.2012 08:24, schrieb Thomas Jarosch:
> > libftdi is not designed to be thread safe.
> 
> But libusb-win32 is threadsafe? According to
> http://libusb.6.n5.nabble.com/Thread-safety-and-driver-file-name-td327842
> 0.html
> 
> So, if I patch the libftdi-calls that I use to do locking
> then I am safe?

The above link states you are safe if you don't send
USB control messages at the same time.

If you protect all your ftdi_xxx() calls with a lock, you're fine.

> I want to read and write at the same time in different threads
> from/to a FT2232H chip...

That should work. You still have to use proper locking if f.e.
a "background" thread collects data via ftdi_read_data() and you also
call ftdi_read_data() from the "main" thread. (Multi core systems
might see different values for ftdi->readbufer_XXX otherwise)

Thomas

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

headers

Rogier Wolff | 25 Apr 2012 10:35

Re: libftdi 0.x thread recommendations

On Wed, Apr 25, 2012 at 09:29:51AM +0200, Thomas Jarosch wrote:
> That should work. You still have to use proper locking if f.e.
> a "background" thread collects data via ftdi_read_data() and you also
> call ftdi_read_data() from the "main" thread. (Multi core systems
> might see different values for ftdi->readbufer_XXX otherwise)

Is it safe to have a "reading" thread that does all the reading, while
another thread does some writing? My reading-thread dumps the data
into a properly locked (*) shared memory buffer and the "main" thread
reads from there.

	Roger. 

(*) Actually no locks involved. If you program it wisely there is no
need.

--

-- 
** R.E.Wolff <at> BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

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

headers

Uwe Bonnes | 25 Apr 2012 10:45

Re: libftdi 0.x thread recommendations

>>>>> "Rogier" == Rogier Wolff <R.E.Wolff <at> BitWizard.nl> writes:

    Rogier> On Wed, Apr 25, 2012 at 09:29:51AM +0200, Thomas Jarosch wrote:
    >> That should work. You still have to use proper locking if f.e.  a
    >> "background" thread collects data via ftdi_read_data() and you also
    >> call ftdi_read_data() from the "main" thread. (Multi core systems
    >> might see different values for ftdi->readbufer_XXX otherwise)

    Rogier> Is it safe to have a "reading" thread that does all the reading,
    Rogier> while another thread does some writing? My reading-thread dumps
    Rogier> the data into a properly locked (*) shared memory buffer and the
    Rogier> "main" thread reads from there.

I think to. It is the way I understand the FTD2xx library.

Would you mind to share an example for your threaded code?

Thanks
--

-- 
Uwe Bonnes                bon <at> elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

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

headers

Xiaofan Chen | 25 Apr 2012 11:39

Re: libftdi 0.x thread recommendations

On Tue, Apr 24, 2012 at 10:46 PM, Thomas Heller <theller <at> ctypes.org> wrote:
> Am 24.04.2012 08:24, schrieb Thomas Jarosch:
>
>> libftdi is not designed to be thread safe.
>
>
> But libusb-win32 is threadsafe? According to
> http://libusb.6.n5.nabble.com/Thread-safety-and-driver-file-name-td3278420.html
>
> So, if I patch the libftdi-calls that I use to do locking
> then I am safe?
>
> I want to read and write at the same time in different threads
> from/to a FT2232H chip...
>

I am not an expert in this discussion, but Travis has an example
for libusb-win32 and Windows threading.
http://sourceforge.net/apps/trac/libusb-win32/browser/trunk/libusb/examples/benchmark.c

--

-- 
Xiaofan

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