ENRIQUE ARIZON BENITO | 1 Jul 08:56 2009
Picon

Doubts about Libusb on Linux

Hi all,

 I'm stuck with an usb related problem. I was trying to create a remote control as explained in this link: http://www.huitsing.nl/irftdi/ that basically generate pulses as the USB start sending "0"s and "1"s to the chip. I build the hardware and it works great for short pulses, but as the pulse size increase random delays are inserted into the generated signal.

Digging into the Linux USB programming guides I found that probably the best way to send data to the kernel is through a linked list of URBs. As explained in http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/node23.html:

"next [optional input parameter]

  It is possible to link several URBs in a chain by using the next pointer. This allows you to send a sequence of USB transfer requests to the USB core. The chain has to be terminated by a NULL pointer or the last URB has to be linked with the first.
This allows to automatically reschedule a number of URBs to transfer a continous data stream."

My doubt come next:
 While using libusb-compat/libusb (the IR remote control makes use of the ftdi library that depends on libusb-0.1) I have found no similar API interface that provides for linked list of data, just the possibility to send a buffer with a given size and length. I don't known if there is any possibility to send a list of data so that the kernel manages it as a continuous stream, or the library does so automatically or maybe that possibility is not allowed at this moment/is not planned at all or maybe I'm completely wrong and it makes no difference to send separate USB bulk transfers that sending a unique bulk transfer with a link of data.


Regards,

Enrique
------------------------------------------------------------------------------
_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
ENRIQUE ARIZON BENITO | 1 Jul 09:45 2009
Picon

Re: Doubts about Libusb on Linux

Hi again,
 after browsing a modern linux kernel I noticed the link I posted about URB was completely outdated and it doesn't apply anymore.

Still my doubt persists. Basically I don't know if there is a way to force data to be send out to the usb device in bulk transfers without random delays (considering the best test-case scenario that no other usb devices are attached to the bus)


Regards

Enrique



On Wed, Jul 1, 2009 at 8:56 AM, ENRIQUE ARIZON BENITO <enrique.arizonbenito <at> gmail.com> wrote:
Hi all,

 I'm stuck with an usb related problem. I was trying to create a remote control as explained in this link: http://www.huitsing.nl/irftdi/ that basically generate pulses as the USB start sending "0"s and "1"s to the chip. I build the hardware and it works great for short pulses, but as the pulse size increase random delays are inserted into the generated signal.

Digging into the Linux USB programming guides I found that probably the best way to send data to the kernel is through a linked list of URBs. As explained in http://www.lrr.in.tum.de/Par/arch/usb/usbdoc/node23.html:

"next [optional input parameter]

  It is possible to link several URBs in a chain by using the next pointer. This allows you to send a sequence of USB transfer requests to the USB core. The chain has to be terminated by a NULL pointer or the last URB has to be linked with the first.
This allows to automatically reschedule a number of URBs to transfer a continous data stream."

My doubt come next:
 While using libusb-compat/libusb (the IR remote control makes use of the ftdi library that depends on libusb-0.1) I have found no similar API interface that provides for linked list of data, just the possibility to send a buffer with a given size and length. I don't known if there is any possibility to send a list of data so that the kernel manages it as a continuous stream, or the library does so automatically or maybe that possibility is not allowed at this moment/is not planned at all or maybe I'm completely wrong and it makes no difference to send separate USB bulk transfers that sending a unique bulk transfer with a link of data.


Regards,

Enrique

------------------------------------------------------------------------------
_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
loody | 1 Jul 13:46 2009
Picon

How can I open usb device without knowing the vender and device id

Dear all:
I download the libusb window's version.
And there is an example shows how to recognize USB flash by vendor and
device id.
Is there better way like use "g:\" to open the device and r/w it
instead of filling the vendor/device id by hand.
appreciate your help,
miloody

------------------------------------------------------------------------------
Alan Stern | 1 Jul 16:13 2009
Picon

Re: Doubts about Libusb on Linux

On Wed, 1 Jul 2009, ENRIQUE ARIZON BENITO wrote:

> Hi again,
>  after browsing a modern linux kernel I noticed the link I posted about URB
> was completely outdated and it doesn't apply anymore.
> 
> Still my doubt persists. Basically I don't know if there is a way to force
> data to be send out to the usb device in bulk transfers without random
> delays (considering the best test-case scenario that no other usb devices
> are attached to the bus)

With bulk transfers, assuming no other devices are attached to the USB
bus, the random delays introduced by the kernel's USB stack and the
hardware should never be much longer than 1 ms.

Now, it's possible that your program is getting delayed by other 
running tasks.  This would mean that there are delays in the bulk 
transfer submissions.  If that's the case you'll have to fix it 
yourself by changing your programs priority.

Alan Stern

------------------------------------------------------------------------------
Alan Stern | 1 Jul 16:35 2009
Picon

Re: How can I open usb device without knowing the vender and device id

On Wed, 1 Jul 2009, loody wrote:

> Dear all:
> I download the libusb window's version.
> And there is an example shows how to recognize USB flash by vendor and
> device id.
> Is there better way like use "g:\" to open the device and r/w it
> instead of filling the vendor/device id by hand.

Sure there is: Don't use libusb, use regular Windows disk I/O instead.

Alan Stern

------------------------------------------------------------------------------
ENRIQUE ARIZON BENITO | 1 Jul 19:24 2009
Picon

Re: Doubts about Libusb on Linux

Solved!

In the end it was not caused by the USB software. I wrote Albert Huitsin (http://www.huitsing.nl/irftdi/) that told me he was informed from the USB hardware maker FTDI that "there is a known issue in silicon with synchronizing the USB clock to the output clock". He was also suffering the same delays in the signal output. With that "issue in silicon" in mind I made various tests and found a solution. The FTDI chip just admit/works fine with "power of two" baud rates frequencies, while normal modem baud rates (9600,37500,...) cause the mentioned random lags.

Regards,

Enrique

P.S:
Unfortunately Albert told me FTDI is aware of the problem but they propose a non-sense pitfall solution that, worst at all, does not work (using always the maximum baud rate 3000000 and padding with zeros and ones while the internal clock start working). If someone in this list is going to use such chips in any real project (FTDI chips are widely used in industry), you better writte down this mail as a reference.

On Wed, Jul 1, 2009 at 4:13 PM, Alan Stern <stern <at> rowland.harvard.edu> wrote:
On Wed, 1 Jul 2009, ENRIQUE ARIZON BENITO wrote:

> Hi again,
>  after browsing a modern linux kernel I noticed the link I posted about URB
> was completely outdated and it doesn't apply anymore.
>
> Still my doubt persists. Basically I don't know if there is a way to force
> data to be send out to the usb device in bulk transfers without random
> delays (considering the best test-case scenario that no other usb devices
> are attached to the bus)

With bulk transfers, assuming no other devices are attached to the USB
bus, the random delays introduced by the kernel's USB stack and the
hardware should never be much longer than 1 ms.

Now, it's possible that your program is getting delayed by other
running tasks.  This would mean that there are delays in the bulk
transfer submissions.  If that's the case you'll have to fix it
yourself by changing your programs priority.

Alan Stern


------------------------------------------------------------------------------
_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel
Michael Plante | 1 Jul 21:03 2009
Picon

Re: Doubts about Libusb on Linux

Enrique,

If you can, would you please elaborate on:

1) Which FTDI models have this issue  (sounds like this one is MM232R, but maybe others have problems, too?)

2) Whether any modes besides bit-bang mode (as described in Albert's page) are affected

Thanks,
Michael Plante

-----Original Message-----
From: ENRIQUE ARIZON BENITO [mailto:enrique.arizonbenito <at> gmail.com]
Sent: Wednesday, July 01, 2009 12:25 PM
To: libusb-devel <at> lists.sourceforge.net
Subject: Re: [Libusb-devel] Doubts about Libusb on Linux

Solved!

In the end it was not caused by the USB software. I wrote Albert Huitsin (http://www.huitsing.nl/irftdi/)
that told me he was informed from the USB hardware maker FTDI that "there is a known issue in silicon with
synchronizing the USB clock to the output clock". He was also suffering the same delays in the signal
output. With that "issue in silicon" in mind I made various tests and found a solution. The FTDI chip just
admit/works fine with "power of two" baud rates frequencies, while normal modem baud rates
(9600,37500,...) cause the mentioned random lags. 

Regards,

Enrique

P.S:
Unfortunately Albert told me FTDI is aware of the problem but they propose a non-sense pitfall solution
that, worst at all, does not work (using always the maximum baud rate 3000000 and padding with zeros and
ones while the internal clock start working). If someone in this list is going to use such chips in any real
project (FTDI chips are widely used in industry), you better writte down this mail as a reference.

On Wed, Jul 1, 2009 at 4:13 PM, Alan Stern <stern <at> rowland.harvard.edu> wrote:

On Wed, 1 Jul 2009, ENRIQUE ARIZON BENITO wrote:

> Hi again,
>  after browsing a modern linux kernel I noticed the link I posted about URB
> was completely outdated and it doesn't apply anymore.
>
> Still my doubt persists. Basically I don't know if there is a way to force
> data to be send out to the usb device in bulk transfers without random
> delays (considering the best test-case scenario that no other usb devices
> are attached to the bus)

With bulk transfers, assuming no other devices are attached to the USB
bus, the random delays introduced by the kernel's USB stack and the
hardware should never be much longer than 1 ms.

Now, it's possible that your program is getting delayed by other
running tasks.  This would mean that there are delays in the bulk
transfer submissions.  If that's the case you'll have to fix it
yourself by changing your programs priority.

Alan Stern

------------------------------------------------------------------------------
Peter Stuge | 1 Jul 23:49 2009
Picon

Re: Doubts about Libusb on Linux

Dear Michael,

Michael Plante wrote:
> 1) Which FTDI models

Do yourself a favor and choose something else. They simplify too much.
It looks attractive because it is simple, but you can really do SO
much better with USB.

//Peter

------------------------------------------------------------------------------
Tim Roberts | 2 Jul 00:29 2009

Re: Doubts about Libusb on Linux

Peter Stuge wrote:
> Dear Michael,
>
> Michael Plante wrote:
>   
>> 1) Which FTDI models
>>     
>
> Do yourself a favor and choose something else. They simplify too much.
> It looks attractive because it is simple, but you can really do SO
> much better with USB.
>   

Exactly right.  The PIC chips from Microchip that have USB built in
(like the 18F2550) are almost that simple, and have much more
flexibility for the same price ($4 in qty 1).

PIC chips are fun.  I wish I had more excuses to use them.

--

-- 
Tim Roberts, timr <at> probo.com
Providenza & Boekelheide, Inc.

------------------------------------------------------------------------------
Michael Plante | 2 Jul 04:52 2009
Picon

Re: Doubts about Libusb on Linux

Hi Peter and Tim,

Based on the info on the two lists over the time I've been reading, I
would....if it were my choice.  Their d2xx library is buggy (mostly race
conditions and general lack of understanding of threading, both in Win32 and
Linux versions), so I already hold them in pretty low esteem.  That said, my
current stuff works (using a slightly-modified libftdi, not d2xx), but I'm
wondering what future system could hit this roadblock so that I can make an
argument against that option.

Thanks,
Michael

-----Original Message-----
From: Tim Roberts [mailto:timr <at> probo.com]
Sent: Wednesday, July 01, 2009 5:29 PM
To: libusb-devel <at> lists.sourceforge.net
Subject: Re: [Libusb-devel] Doubts about Libusb on Linux

Peter Stuge wrote:
> Dear Michael,
>
> Michael Plante wrote:
>
>> 1) Which FTDI models
>>
>
> Do yourself a favor and choose something else. They simplify too much.
> It looks attractive because it is simple, but you can really do SO
> much better with USB.
>

Exactly right.  The PIC chips from Microchip that have USB built in
(like the 18F2550) are almost that simple, and have much more
flexibility for the same price ($4 in qty 1).

PIC chips are fun.  I wish I had more excuses to use them.

--
Tim Roberts, timr <at> probo.com
Providenza & Boekelheide, Inc.

----------------------------------------------------------------------------
--
_______________________________________________
Libusb-devel mailing list
Libusb-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusb-devel

------------------------------------------------------------------------------

Gmane