Discussion about the development of the cross-platform user space library for accessing usb devices.

ENRIQUE ARIZON BENITO | 1 Jul 2009 08:56

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

headers

ENRIQUE ARIZON BENITO | 1 Jul 2009 09:45

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

headers

loody | 1 Jul 2009 13:46

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

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

headers

Alan Stern | 1 Jul 2009 16:13

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

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

headers

Alan Stern | 1 Jul 2009 16:35

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

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

headers

ENRIQUE ARIZON BENITO | 1 Jul 2009 19:24

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

headers

Michael Plante | 1 Jul 2009 21:03

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

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

headers

Peter Stuge | 1 Jul 2009 23:49

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

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

headers

Tim Roberts | 2 Jul 2009 00:29

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.

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

headers

Michael Plante | 2 Jul 2009 04:52

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

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

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

89	May 2013
182	April 2013
69	March 2013
222	February 2013
83	January 2013
73	December 2012
43	November 2012
100	October 2012
94	September 2012
73	August 2012
119	July 2012
150	June 2012
131	May 2012
230	April 2012
223	March 2012
176	February 2012
111	January 2012
269	December 2011
171	November 2011
162	October 2011
407	September 2011
231	August 2011
301	July 2011
440	June 2011
214	May 2011
305	April 2011
384	March 2011
450	February 2011
518	January 2011
453	December 2010
265	November 2010
480	October 2010
524	September 2010
501	August 2010
357	July 2010
567	June 2010
495	May 2010
647	April 2010
462	March 2010
575	February 2010
681	January 2010
180	December 2009
120	November 2009
148	October 2009
275	September 2009
153	August 2009
125	July 2009
206	June 2009
229	May 2009
180	April 2009
60	March 2009
145	February 2009
197	January 2009
79	December 2008
104	November 2008
135	October 2008
116	September 2008
118	August 2008
218	July 2008
259	June 2008
405	May 2008
126	April 2008
85	March 2008
81	February 2008
141	January 2008
78	December 2007
196	November 2007
108	October 2007
81	September 2007
58	August 2007
55	July 2007
66	June 2007
243	May 2007
413	April 2007
245	March 2007
147	February 2007
64	January 2007
42	December 2006
339	November 2006
76	October 2006
37	September 2006
77	August 2006
58	July 2006
29	June 2006
63	May 2006
58	April 2006
61	March 2006
115	February 2006
99	January 2006
112	December 2005
63	November 2005
41	October 2005
44	September 2005
46	August 2005
31	July 2005
26	June 2005
25	May 2005
53	April 2005
31	March 2005
92	February 2005
58	January 2005
37	December 2004
36	November 2004
38	October 2004