libusb-devel Mailing List for libusb

David C Moore wrote:
> Quoting Daniel Drake <ds...@ge...>:
>> It's a bug in libusb, sorry. The solution is for libusb to memmove the
>> "extra" data into the appropriate position and to increase the reported
>> "bytes transferred" length of the transfer appropriately.
> 
> Unfortunately, I don't think a solution like that would work properly.  
> Most
> devices transfer a short packet to indicate the logical end of a large
> transfer.  If additional bytes are concatenated onto the end of the buffer
> after the short packet, that would generally violate the expectations of 
> the
> programmer.

I agree that a fundamental design change (starting from kernel level) 
may be in order to solve this properly.

In the mean time, the least that libusb can do is not lose the data, and 
this behaviour could be documented. Giving the programmer the choice is 
better, even if it is then hard for the programmer to follow through...

libusb could also offer the ability to run a non-parallelized bulk 
transfer, submitting one URB at a time, for those who desire it.

Daniel

Hi Daniel,
Thanks very much for the insight.  It is really appreciated!

Sincerely, Barry P...

-----Original Message-----
From: Daniel Drake [mailto:ds...@ge...] 
Sent: Wednesday, February 25, 2009 10:43 AM
To: Barry Pasicznyk
Cc: lib...@li...
Subject: Re: [Libusb-devel] warning message: SOME DATA LOST!

Barry Pasicznyk wrote:
> Hi,
> I'm using libusb 1.0 to do synchronous transfers (bulk transfer) and 
> every once in a while I get an warning:
>  
> libusb:warning [handle_bulk_completion] SOME DATA LOST! (completed 
> early but remaining urb completed)

It indicates the following scenario:

  1. Your application asked for a lot of data
  2. libusb divided up the request into several packets
  3. One packet terminated before it was filled, so libusb assumed that
     the transfer was finished and quickly cancelled all the remaining
     packets.
  4. The cancellation was not quick enough; a further packet completed
     (maybe only partially) before the cancellation was able to happen.

libusb doesn't have code to deal with (4) so it discarded the data (but
produced a warning). I wasn't sure if we'd ever see this.

It's a bug in libusb, sorry. The solution is for libusb to memmove the
"extra" data into the appropriate position and to increase the reported
"bytes transferred" length of the transfer appropriately. And then we
should document that this sequence of events is perhaps not all that
unlikely.

I'm a bit tied up with things right now but I'll aim to work on this
(and the other data loss issue) soon.... in the mean time, patches are
happily considered.

Thanks & apologies!
Daniel

Barry Pasicznyk wrote:
> Hi,
> I'm using libusb 1.0 to do synchronous transfers (bulk transfer) and 
> every once in a while I get an warning:
>  
> libusb:warning [handle_bulk_completion] SOME DATA LOST! (completed early 
> but remaining urb completed)

It indicates the following scenario:

  1. Your application asked for a lot of data
  2. libusb divided up the request into several packets
  3. One packet terminated before it was filled, so libusb assumed that
     the transfer was finished and quickly cancelled all the remaining
     packets.
  4. The cancellation was not quick enough; a further packet completed
     (maybe only partially) before the cancellation was able to happen.

libusb doesn't have code to deal with (4) so it discarded the data (but 
produced a warning). I wasn't sure if we'd ever see this.

It's a bug in libusb, sorry. The solution is for libusb to memmove the 
"extra" data into the appropriate position and to increase the reported 
"bytes transferred" length of the transfer appropriately. And then we 
should document that this sequence of events is perhaps not all that 
unlikely.

I'm a bit tied up with things right now but I'll aim to work on this 
(and the other data loss issue) soon.... in the mean time, patches are 
happily considered.

Thanks & apologies!
Daniel

Nathan Hjelm wrote:
> Change those lines to use USBI_CLOCK_MONOTONIC and USBI_CLOCK_REALTIME respectively.


Oops, my mistake. Forgot to update the darwin backend after tweaking 
your work. Fixed in git.

Thanks!

Jeffrey Price wrote:
>
> There is gpif handshaking between the internal fifo of the fx2 and an
> external fifo on the board. The logic there says if the external fifo
> is not full and the internal fifo flag is not empty, then tx enable is
> asserted and data transfers from the internal fifo to the external fifo.

This indirectly answers one of the questions I asked.  There are two
ways to connect an outside source to the FIFOs on an FX2.  In "slave
FIFO" mode, the FIFOs are just slaves to external read/write signals. 
They are essentially just big, dumb buffers, at the mercy of the outside
data handler.  In "GPIF" mode, the FX2 is much more in control.  You
provide a set of timing equations in the firmware that dictate exactly
how data is funneled to and from the FIFOs.  In our experience, the GPIF
mode is much more delicate and error prone, and because of that, we no
longer use it in our designs.


> The failure mode I notice is if I send a packet < 512 bytes (I know
> that is the USB packet size for a single packet), it gets through the
> first time, but not any subsequent times. Then if I send a larger
> packet (2048 bytes), that goes through and then I can send the small
> one. (When the small one does not come through; it is not seen in the
> external fifo, and it appears like the fifo empty flag for the
> internal fifo never changes to not empty.
>
> So it seems that small (<512) pkts only make it to the external fifo, 
> if a bigger one has preceded it. I know this does sound like a fifo
> management issue, but the same firmware and gpif logic work with small
> packets under windows.
>  
> You have already given me some good things to think about, but do you
> have any other ideas ?

I really think you need to find the firmware and take a good, close look
at the GPIF data structures.  My guess is that you have a corner case
that was not anticipated.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Jan Wilmans wrote:
> I have had the same problem, "it works on windows" and I have never
> been able to "prove" what I'm about to say but:
>
> In my experience, when a project starts out on windows and is then
> ported to linux, much compatibility problems can arise and I strongly
> suspect, this is because the windows usb-stack does not conform to the
> usb standards and applications (unknowningly) rely on this
> non-standard behaviour.
>   

For what it's worth, this has actually improved with each release.
Windows 2000 was extremely forgiving (and encouraged a lot of bad
behavior), but Windows XP was slightly less so, and in Vista they
tightened things up considerably.  So, there may be hope for the future.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Hi,
I'm using libusb 1.0 to do synchronous transfers (bulk transfer) and
every once in a while I get an warning:
 
libusb:warning [handle_bulk_completion] SOME DATA LOST! (completed early
but remaining urb completed)

I looked around in the libusb code and in file linux_usbfs.c, function
handle_bulk_completion I found the following code fragment:

 if (tpriv->reap_action != NORMAL) {
  /* cancelled, submit_fail, or completed early */
  if (urb->status == 0 && tpriv->reap_action == COMPLETED_EARLY) {
   /* FIXME we could solve this extreme corner case with a memmove 
    * or something */   
   usbi_warn(ITRANSFER_CTX(itransfer), "SOME DATA LOST! "
    "(completed early but remaining urb completed)");
  }
  usbi_dbg("CANCEL: urb status %d", urb->status);
  ...

I am unsure what this warning actually means.  Any suggestions or
comments would be appreciated.
 
Thanks for your time (and sorry if this is a stupid question).
 
Sincerely,
Barry P...
 

> I know it sure sounds like libusb is out of the picture. The troubling thing
> is the same application code and fx2 firmware works with the Windows driver.

I have had the same problem, "it works on windows" and I have never
been able to "prove" what I'm about to say but:

In my experience, when a project starts out on windows and is then
ported to linux, much compatibility problems can arise and I strongly
suspect, this is because the windows usb-stack does not conform to the
usb standards and applications (unknowningly) rely on this
non-standard behaviour.

I started out by using the FTD2xx driver on windows and my application
worked fine except for minor "flukes", which I blamed on hardware
instability, electrical spikes etc and other unlikely scenarios. When
I switched to linux, my application showed all kinds of timing issues,
I got loads of (high level) protocol retries etc.

First I blamed it on the FTDI's binary driver (FTD2xx for linux), so I
switched to libftdi (on top of libusb) this didn't help at all, in
fact the problems only seemed to get worse. Then I tried the kernel
driver FTDISIO, I couldn't get this to work at all.

Finally, I started testing basic communication from scratch, first
using libftdi, this worked well and I began to rebuild my application
protocol from scratch.
When it was done I rewrote the driver-layer to work on either libftdi
on linux, ftd2xx on linux, ftdisio on linux, libftdi on libusb-win32,
and FTD2xx on windows, it all works fine now. (this wasn't really
needed, but I wanted to rule out driver-specific behaviour in my
application, and frankly, it was fun :)

In retrospect: my application protocol was not able to deal with
buffer underruns on the FTDI device, but on windows these underruns
(almost) never occurred!
I don't know exactly why... but maybe it's related to the way devices
are polled, maybe more or less frequently or just different? I don't
know enough about the USB protocol to be sure but for example: I think
usb devices are polled every ~1ms, if on linux this behaviour is:
- poll each device once for data and move on the next one
and on windows:
- poll each device for data and if it has more data, poll it again
before moving to the next one

Then this would explain part of the trouble I've seen, unfortunately I
don't have the equipment to find out I any of this is true :)

greetings,

Jan Wilmans

Thanks Tim.

I know it sure sounds like libusb is out of the picture. The troubling thing is the same application code and fx2 firmware works with the Windows driver.

Good point and I understand about visibility using the  firmware, but unfortunately I did not write it and do not know who did. I will try to track the sucker down though and ask him to help out by checking things out in his fw or perhaps putting in some debug logic.

There is gpif handshaking between the internal fifo of the fx2 and an external fifo on the board. The logic there says if the external fifo is not full and the internal fifo flag is not empty, then tx enable is asserted and data transfers from the internal fifo to the external fifo.

I know the polarity of the fifo flags are correct. In most cases the handshaking works and data is transferred into the external fifo. 

The failure mode I notice is if I send a packet < 512 bytes (I know that is the USB packet size for a single packet), it gets through the first time, but not any subsequent times. Then if I send a larger packet (2048 bytes), that goes through and then I can send the small one. (When the small one does not come through; it is not seen in the external fifo, and it appears like the fifo empty flag for the internal fifo never changes to not empty.

So it seems that small (<512) pkts only make it to the external fifo,  if a bigger one has preceded it. I know this does sound like a fifo management issue, but the same firmware and gpif logic work with small packets under windows.

 
You have already given me some good things to think about, but do you have any other ideas ? 

Thank you much


Jeff Price

Peace,Love,Happiness, and Fun,






________________________________
From: Tim Roberts <ti...@pr...>
To: lib...@li...
Sent: Monday, February 23, 2009 11:20:30 AM
Subject: Re: [Libusb-devel] can send only packets pne time

jeffp wrote:
> I am having a strange problem where I reboot my device (Digital Input to
> USB) streamer,  I can send 1 packet less than 512 bytes (USB pkt size) but
> then cannot send any others. I do see the 2nd packet on the sniffer but it
> never gets past the USB part (using logic scope) on the device.
>  

If you see the packet on the bus with a sniffer, then it should be
obvious that libusb is not at fault.

> The USB device is a fx2 processor which uses EZ-USB. The fx2 has an internal
> FIFO which feeds an external FIFO on the device whenever there is data in
> the internal fx2 FIFO. It seems the pkts do not get into the internal fx2
> FIFO (past the USB PHY).
>  

So, are you using the FX2 FIFOs in slave mode?  Do you have AUTOOUT
set?  How is your device deciding when to pull data from the FX2 FIFOs? 
Remember, the FX2 does not "push" data out of the FIFOs.  An external
device has to "pull" the data, based on the empty/full flags.  Have you
checked your empty/full flags to make sure you have the polarity
correct?  Are you, in fact, using the "FIFO empty" flag to decide when
to pull more data?

> Has anyone seen anything similar to this or have any ideas of what may be
> going on or what I can check ? Unfortunately I have no visibility inside the
> fx2.
>  

That's not true!  YOU control the firmware, and the firmware has 100%
visibility of and control over the internal state.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Libusb-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libusb-devel



      

Change those lines to use USBI_CLOCK_MONOTONIC and USBI_CLOCK_REALTIME respectively.

-Nathan
 
On Monday, February 23, 2009, at 01:30PM, "???????" <ihr...@gm...> wrote:
>Hello!
>
>I'm trying to install libusb on my mac, it's running last version of  
>leopard.
>
>I've downloaded the "Darwin backend" snapshot ( http://projects.reactivated.net/cgi-bin/gitweb.cgi?p=libusb.git;a=snapshot;h=b49f6bf5c910d0fd694ecf165d7927673707bff9;sf=tgz 
>  )
>
>and then in terminal, under root:
>./autogen.sh
>./configure
>
>and then I tried a make command and got
>os/darwin_usb.c:1394: error: 'LIBUSB_CLOCK_MONOTONIC' undeclared  
>(first use in this function)
>
>So I've attached a full output of a make to this letter.
>
>I do hope it's easy to fix or I've missed smth.
>
>
>make  all-recursive
>Making all in libusb
>/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..    -fvisibility=hidden -std=gnu99  -Wall -Wundef -Wunused -Wstrict-prototypes -Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -pthread -g -O2 -MT libusb_1_0_la-darwin_usb.lo -MD -MP -MF .deps/libusb_1_0_la-darwin_usb.Tpo -c -o libusb_1_0_la-darwin_usb.lo `test -f 'os/darwin_usb.c' || echo './'`os/darwin_usb.c
> gcc -DHAVE_CONFIG_H -I. -I.. -fvisibility=hidden -std=gnu99 -Wall -Wundef -Wunused -Wstrict-prototypes -Werror-implicit-function-declaration -Wno-pointer-sign -Wshadow -pthread -g -O2 -MT libusb_1_0_la-darwin_usb.lo -MD -MP -MF .deps/libusb_1_0_la-darwin_usb.Tpo -c os/darwin_usb.c  -fno-common -DPIC -o .libs/libusb_1_0_la-darwin_usb.o
>In file included from ./libusbi.h:31,
>                 from os/darwin_usb.h:23,
>                 from os/darwin_usb.c:43:
>./libusb.h:1097: warning: declaration of 'index' shadows a global declaration
>/usr/include/string.h:125: warning: shadowed declaration is here
>./libusb.h:1151: warning: declaration of 'index' shadows a global declaration
>/usr/include/string.h:125: warning: shadowed declaration is here
>os/darwin_usb.c: In function 'process_new_device':
>os/darwin_usb.c:419: warning: unused variable 'info'
>os/darwin_usb.c: In function 'darwin_clock_gettime':
>os/darwin_usb.c:1390: error: 'LIBUSB_CLOCK_REALTIME' undeclared (first use in this function)
>os/darwin_usb.c:1390: error: (Each undeclared identifier is reported only once
>os/darwin_usb.c:1390: error: for each function it appears in.)
>os/darwin_usb.c:1394: error: 'LIBUSB_CLOCK_MONOTONIC' undeclared (first use in this function)
>make[2]: *** [libusb_1_0_la-darwin_usb.lo] Error 1
>make[1]: *** [all-recursive] Error 1
>make: *** [all] Error 2
>
>
>
>
>Looking forward for your replay,
>Roman
>------------------------------------------------------------------------------
>Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>-Strategies to boost innovation and cut costs with open source participation
>-Receive a $600 discount off the registration fee with the source code: SFAD
>http://p.sf.net/sfu/XcvMzF8H
>_______________________________________________
>Libusb-devel mailing list
>Lib...@li...
>https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>

Hello!

I'm trying to install libusb on my mac, it's running last version of  
leopard.

I've downloaded the "Darwin backend" snapshot ( http://projects.reactivated.net/cgi-bin/gitweb.cgi?p=libusb.git;a=snapshot;h=b49f6bf5c910d0fd694ecf165d7927673707bff9;sf=tgz 
  )

and then in terminal, under root:
./autogen.sh
./configure

and then I tried a make command and got
os/darwin_usb.c:1394: error: 'LIBUSB_CLOCK_MONOTONIC' undeclared  
(first use in this function)

So I've attached a full output of a make to this letter.

I do hope it's easy to fix or I've missed smth.

jeffp wrote:
> I am having a strange problem where I reboot my device (Digital Input to
> USB) streamer,  I can send 1 packet less than 512 bytes (USB pkt size) but
> then cannot send any others. I do see the 2nd packet on the sniffer but it
> never gets past the USB part (using logic scope) on the device.
>   

If you see the packet on the bus with a sniffer, then it should be
obvious that libusb is not at fault.

> The USB device is a fx2 processor which uses EZ-USB. The fx2 has an internal
> FIFO which feeds an external FIFO on the device whenever there is data in
> the internal fx2 FIFO. It seems the pkts do not get into the internal fx2
> FIFO (past the USB PHY).
>   

So, are you using the FX2 FIFOs in slave mode?  Do you have AUTOOUT
set?  How is your device deciding when to pull data from the FX2 FIFOs? 
Remember, the FX2 does not "push" data out of the FIFOs.  An external
device has to "pull" the data, based on the empty/full flags.  Have you
checked your empty/full flags to make sure you have the polarity
correct?  Are you, in fact, using the "FIFO empty" flag to decide when
to pull more data?

> Has anyone seen anything similar to this or have any ideas of what may be
> going on or what I can check ? Unfortunately I have no visibility inside the
> fx2.
>   

That's not true!  YOU control the firmware, and the firmware has 100%
visibility of and control over the internal state.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

puneetnepsam wrote:
> warnings are coming : 
>
> usbdevicedetails.c:106: warning: conflicting types for âfprint_configurationâ
> usbdevicedetails.c:4: warning: previous declaration of âfprint_configurationâ was here
> usbdevicedetails.c: In function âfprint_configurationâ:
> usbdevicedetails.c:129: warning: passing argument 1 of âfprint_altsettingâ discards qualifiers from pointer target type
> usbdevicedetails.c: At top level:
> usbdevicedetails.c:135: warning: conflicting types for âfprint_altsettingâ
> usbdevicedetails.c:6: warning: previous declaration of âfprint_altsettingâ was here
> usbdevicedetails.c: In function âfprint_altsettingâ:
> usbdevicedetails.c:143: warning: passing argument 1 of âfprint_interfaceâ
> discards qualifiers from pointer target type
> usbdevicedetails.c: At top level:
> usbdevicedetails.c:150: warning: conflicting types for âfprint_interfaceâ
> usbdevicedetails.c:5: warning: previous declaration of âfprint_interfaceâ was here
> usbdevicedetails.c: In function âfprint_interfaceâ:
> usbdevicedetails.c:171: warning: passing argument 1 of âfprint_endpointâ discards qualifiers from pointer target type 
>
> can you please give me the reason why is it??
>   

Come on, Puneet.  These are elementary C questions, and the error
messages could not possible be more clear.  Look at the first error:

> usbdevicedetails.c:106: warning: conflicting types for âfprint_configurationâ
> usbdevicedetails.c:4: warning: previous declaration of âfprint_configurationâ was here
>   

So, look at line 4:
> void fprint_configuration(struct libusb_config_descriptor *,libusb_device *);
>   

Then look at line 106:
> fprint_configuration(struct libusb_config_descriptor *config,libusb_device *found)
>   

Do those look the same to you?

Then, look at the next one:
> usbdevicedetails.c: In function âfprint_configurationâ:
> usbdevicedetails.c:129: warning: passing argument 1 of âfprint_altsettingâ discards qualifiers from pointer target type
>   

Again, this seems pretty clear.   If you look at the definition of
libusb_config_descriptor, you'll see that the "interface" member is
declared like this:
        const struct libusb_interface *interface;

You are passing it to a function that wants a "struct libusb_interface
*" without the "const".  That's an error.  You should change your
functions to use "const" for these structures.  That way, the compiler
will warn you if you accidentally try to change them, just as it did here.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Peter Stuge wrote:
> Danil Smirnov wrote:
>   
>> You are wrong.
>> I`ve get this error after development packages installation.
>> It´s another error if gcc is not found.
>>     
>
> Interesting.
>
> Your config.log showed a problem executing cpp, the C preprocessor,
> which should be part of the gcc package.
>
> Do you have a cpp in your system? Try which cpp
>   

It found cpp, but cpp failed to find linux/limits.h.  So, he has
installed "gcc" but is apparently missing one of the core Linux
development packages.

He's building on an eeePC, which is not only Xandros, but a
stripped-down and modified Xandros, aimed at unsophisticated consumers,
not at developers.  Danil, I suggest you go ask on one of the many eeePC
forums to find out exactly which packages you need to install to do this
kind of development.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Danil Smirnov wrote:
> You are wrong.
> I`ve get this error after development packages installation.
> It´s another error if gcc is not found.

Interesting.

Your config.log showed a problem executing cpp, the C preprocessor,
which should be part of the gcc package.

Do you have a cpp in your system? Try which cpp


//Peter

You are wrong.
I`ve get this error after development packages installation.
It´s another error if gcc is not found.

2009/2/22 Peter Stuge <pe...@st...>

> Danil Smirnov wrote:
> > I trying to install libusb on my netbook and get the error:
> > configure: error: in `/home/user/libusb-1.0.0`:
>
> You need to install some developer packages. There is no C compiler
> installed in the default Xandros system.
>
>
> //Peter
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Danil Smirnov wrote:
> I trying to install libusb on my netbook and get the error:
> configure: error: in `/home/user/libusb-1.0.0`:

You need to install some developer packages. There is no C compiler
installed in the default Xandros system.


//Peter

Hello all!

I trying to install libusb on my netbook and get the error:
configure: error: in `/home/user/libusb-1.0.0`:
configure: error: C preprocessor ¨/lib/cpp¨ fails sanity check

Could anybody help?

Danil

Could anyone provide an example of using
select + libusb_handle_events_timeout?

I am trying to wait for libusb or stdin activity
and there are many details thar are not clear for me.
I'd like to see a working example of handling it correctly,
preferably as another sample file among the rest of libusb examples.




Pozdrawiam
--
Maciej "Fiedzia" Dziardziel
mac...@wp...

----------------------------------------------------
Rodzinne kibicowanie na Cracovii. 
Przy zakupie karnetu mecz Ekstraklasy już od 11 zł! 
Dzieci bezpłatnie, Panie za 1 zł! 
Więcej na: http://klik.wp.pl/?adr=www.cracovia.pl&sid=647

sorr its:
gcc -c usbdevicedetails.c


puneetnepsam wrote:
> 
> #include <stdio.h>
> 
> #include "libusb.h"
> 
>  
> 
> void fprint_configuration(struct libusb_config_descriptor *,libusb_device
> *);
> 
> void fprint_interface(struct libusb_interface_descriptor *);
> 
> void fprint_altsetting(struct libusb_interface *);
> 
> void fprint_endpoint(struct libusb_endpoint_descriptor *);
> 
>  
> 
> int main()
> 
> {
> 
>         /*initialize libusb*/
> 
>         libusb_init(NULL);
> 
>  
> 
>  
> 
>  
> 
>         /*device handling and enumeration */
> 
>         libusb_device **list;
> 
>         libusb_device *found = NULL;
> 
>         struct libusb_device_descriptor ddevice;
> 
>         struct libusb_config_descriptor config;
> 
>         ssize_t count=0;
> 
>  
> 
>  
> 
>         size_t index = 0;
> 
>         int dindex = 0;
> 
>         int no_of_config;
> 
>         int open =1;
> 
>         int des,bus,addr;
> 
>         count = libusb_get_device_list(NULL,&list);     /*to obtain the
> list of the devices connected to the system*/
> 
>  
> 
>         if(count <= 7)
> 
>         {
> 
>                 printf("device not found on the HOST");
> 
>         }
> 
>  
> 
>         printf("\n\nNumber of devices connected to the system are
> %d\n\n",(count-7));
> 
>  
> 
>         for(index=7;index<count;index++)
> 
>         {
> 
>  
> 
>                 libusb_device *device = list[index];
> 
>                 found = device;
> 
>  
> 
>                 libusb_device_handle *handle;
> 
>  
> 
>  
> 
>                 open = libusb_open(found,&handle);      /*opening a usb
> device */
> 
>                 printf("\n the value returned by libusb_open is %d",open);
> 
>  
> 
>                 if(open < 0)
> 
>                 {
> 
>                         printf("\nCannot open the device");
> 
>                 }
> 
>                 printf("\nSuccessfully opened the device");
> 
>  
> 
>  
> 
>                 des = libusb_get_device_descriptor(found,&ddevice);
> 
>                 printf("\nthe value returned by
> libusb_get_device_descriptor is %d",des);
> 
> bus = libusb_get_bus_number(found);
> 
>                 printf("\nthe bus number to which the device is connected
> is %d",bus);
> 
>  
> 
>                 addr = libusb_get_device_address(found);
> 
>                 printf("\nthe address of the device is 0x%02xH\n\n",addr);
> 
>  
> 
>  
> 
>                 printf("\n\n\nDEVICE DESCRIPTOR");
> 
>                 printf("\nblength = %d",ddevice.bLength);
> 
>                 printf("\nbDescriptorType = %d",ddevice.bDescriptorType);
> 
>                 printf("\nbNumConfigurations =
> %d",ddevice.bNumConfigurations);
> 
>                 printf("\nbcdUSB = %d",ddevice.bcdUSB);
> 
>                 printf("\nbDeviceClass = %d",ddevice.bDeviceClass);
> 
>                 printf("\nbDeviceSubClass = %d",ddevice.bDeviceSubClass);
> 
>                 printf("\nbDeviceProtocol = %d",ddevice.bDeviceProtocol);
> 
>                 printf("\nbMaxPacketSize0 = %d",ddevice.bMaxPacketSize0);
> 
>                 printf("\nidVendor = %d",ddevice.idVendor);
> 
>                 printf("\nidProduct = %d",ddevice.idProduct);
> 
>                 printf("\nbcdDevice = %d",ddevice.bcdDevice);
> 
>                 printf("\niManufacturer = %d",ddevice.iManufacturer);
> 
>                 printf("\niProduct = %d",ddevice.iProduct);
> 
>                 printf("\niSerialNumber = %d",ddevice.iSerialNumber);
> 
>                 no_of_config = ddevice.bNumConfigurations;
> 
>  
> 
>                 for(dindex=0;dindex<no_of_config;dindex++)
> 
>                 {
> 
>                         fprint_configuration(&config,found);
> 
>                 }
> 
>                 printf("\n");
> 
>  
> 
>  
> 
>         }
> 
>  
> 
>         libusb_free_device_list(list,1);
> 
>  
> 
>  
> 
>  
> 
>  
> 
>         /*deinitialize libusb*/
> 
>         libusb_exit(NULL);
> 
>  
> 
>  
> 
>         return 0;
> 
> }
> 
>  
> 
>  
> 
> fprint_configuration(struct libusb_config_descriptor *config,libusb_device
> *found)
> 
> {
> 
>  
> 
>         int index;
> 
>         int no_of_interfaces;
> 
>         int cof;
> 
>         cof = libusb_get_active_config_descriptor(found,&config);
> 
>         printf("\n");
> 
>         printf("\n\nCONFIGURATION DESCRIPTOR");
> 
> printf("\nbLength = %d",config->bLength);
> 
>         printf("\nbDescriptorType = %d",config->bDescriptorType);
> 
>         printf("\niConfiguration = %d",config->iConfiguration);
> 
>         printf("\nwTotalLength = %d",config->wTotalLength);
> 
>         printf("\nbNumInterfaces = %d",config->bNumInterfaces);
> 
>         printf("\nbConfigurationValue = %d",config->bConfigurationValue);
> 
>         printf("\niConfiguration = %d",config->bmAttributes);
> 
>         printf("\nMaxPower = %d",config->MaxPower);
> 
>         printf("\nbNumInterfaces = %d",config->bNumInterfaces);
> 
>         no_of_interfaces = config->bNumInterfaces;
> 
>  
> 
>  
> 
>         for(index=0;index<no_of_interfaces;index++)
> 
>         {
> 
>                 fprint_altsetting((config->interface));
> 
>                 (config->interface)++;
> 
>         }
> 
>  
> 
> }
> 
>  
> 
> fprint_altsetting(struct libusb_interface *interface)
> 
> {
> 
>         int index;
> 
>         int no_of_altsettings;
> 
>  
> 
>         no_of_altsettings = interface->num_altsetting;
> 
>         for(index=0;index<no_of_altsettings;index++)
> 
>         {
> 
>                 fprint_interface((interface->altsetting));
> 
>                 (interface->altsetting)++;
> 
>         }
> 
> }
> 
>  
> 
>  
> 
>  
> 
> fprint_interface(struct libusb_interface_descriptor *interface)
> 
> {
> 
>  
> 
>         int index;
> 
>         int no_of_endpoints;
> 
>  
> 
>         printf("\n");
> 
>         printf("\n\nINTERFACE DESCRIPTOR");
> 
>         printf("\nbLength = %d",interface->bLength);
> 
>         printf("\nbInterfaceNumber = %d",interface->bInterfaceNumber);
> 
>         printf("\nbAlternateSetting = %d",interface->bAlternateSetting);
> 
>         printf("\nbNumEndpoints = %d",interface->bNumEndpoints);
> 
>         printf("\nbInterfaceClass = %d",interface->bInterfaceClass);
> 
>         printf("\nbInterfaceSubClass = %d",interface->bInterfaceSubClass);
> 
>         printf("\nbInterfaceProtocol = %d",interface->bInterfaceProtocol);
> 
>         printf("\niInterface = %d",interface->iInterface);
> 
>  
> 
>         no_of_endpoints=interface->bNumEndpoints;
> 
>  
> 
>         for(index=0;index<no_of_endpoints;index++)
> 
>         {
> 
> fprint_endpoint((interface->endpoint));
> 
>                 (interface->endpoint)++;
> 
>         }
> 
>  
> 
> }
> 
>  
> 
>  
> 
>  
> 
> void fprint_endpoint(struct libusb_endpoint_descriptor *endpoint)
> 
> {
> 
>  
> 
>         printf("\n");
> 
>         printf("\n\nENDPOINT DESCRIPTOR");
> 
>         printf("\nbLength = %d",endpoint->bLength);
> 
>         printf("\nbDescriptorType = %d",endpoint->bDescriptorType);
> 
>         printf("\nbEndpointAddress =0x%02x",endpoint->bEndpointAddress);
> 
>         printf("\nbmAttributes = %d",endpoint->bmAttributes);
> 
>         printf("\nwMaxPacketSize = %d",endpoint->wMaxPacketSize);
> 
>         printf("\nbInterval = %d",endpoint->bInterval);
> 
>         printf("\nbRefresh = %d",endpoint->bRefresh);
> 
>         printf("\nbSynchAddress = %d",endpoint->bSynchAddress);
> 
>  
> 
> }
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> Compiling this program 
> 
> gcc –c usbdevicedetails.c
> 
>  
> 
> warnings are coming :
> 
>  
> 
> usbdevicedetails.c:106: warning: conflicting types for
> âfprint_configurationâ
> 
> usbdevicedetails.c:4: warning: previous declaration of
> âfprint_configurationâ was here
> 
> usbdevicedetails.c: In function âfprint_configurationâ:
> 
> usbdevicedetails.c:129: warning: passing argument 1 of âfprint_altsettingâ
> discards qualifiers from pointer target type
> 
> usbdevicedetails.c: At top level:
> 
> usbdevicedetails.c:135: warning: conflicting types for âfprint_altsettingâ
> 
> usbdevicedetails.c:6: warning: previous declaration of âfprint_altsettingâ
> was here
> 
> usbdevicedetails.c: In function âfprint_altsettingâ:
> 
> usbdevicedetails.c:143: warning: passing argument 1 of âfprint_interfaceâ
> discards qualifiers from pointer target type
> 
> usbdevicedetails.c: At top level:
> 
> usbdevicedetails.c:150: warning: conflicting types for âfprint_interfaceâ
> 
> usbdevicedetails.c:5: warning: previous declaration of âfprint_interfaceâ
> was here
> 
> usbdevicedetails.c: In function âfprint_interfaceâ:
> 
> usbdevicedetails.c:171: warning: passing argument 1 of âfprint_endpointâ
> discards qualifiers from pointer target type
> 
>  
> 
>  
> 
>  
> 
> can you please give me the reason why is it??
> 
> Program is running fine
> 
> 

-- 
View this message in context: http://www.nabble.com/warnings-coming-on-implementing-libusb-tp22133247p22133361.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

#include <stdio.h>

#include "libusb.h"

 

void fprint_configuration(struct libusb_config_descriptor *,libusb_device
*);

void fprint_interface(struct libusb_interface_descriptor *);

void fprint_altsetting(struct libusb_interface *);

void fprint_endpoint(struct libusb_endpoint_descriptor *);

 

int main()

{

        /*initialize libusb*/

        libusb_init(NULL);

 

 

 

        /*device handling and enumeration */

        libusb_device **list;

        libusb_device *found = NULL;

        struct libusb_device_descriptor ddevice;

        struct libusb_config_descriptor config;

        ssize_t count=0;

 

 

        size_t index = 0;

        int dindex = 0;

        int no_of_config;

        int open =1;

        int des,bus,addr;

        count = libusb_get_device_list(NULL,&list);     /*to obtain the list
of the devices connected to the system*/

 

        if(count <= 7)

        {

                printf("device not found on the HOST");

        }

 

        printf("\n\nNumber of devices connected to the system are
%d\n\n",(count-7));

 

        for(index=7;index<count;index++)

        {

 

                libusb_device *device = list[index];

                found = device;

 

                libusb_device_handle *handle;

 

 

                open = libusb_open(found,&handle);      /*opening a usb
device */

                printf("\n the value returned by libusb_open is %d",open);

 

                if(open < 0)

                {

                        printf("\nCannot open the device");

                }

                printf("\nSuccessfully opened the device");

 

 

                des = libusb_get_device_descriptor(found,&ddevice);

                printf("\nthe value returned by libusb_get_device_descriptor
is %d",des);

bus = libusb_get_bus_number(found);

                printf("\nthe bus number to which the device is connected is
%d",bus);

 

                addr = libusb_get_device_address(found);

                printf("\nthe address of the device is 0x%02xH\n\n",addr);

 

 

                printf("\n\n\nDEVICE DESCRIPTOR");

                printf("\nblength = %d",ddevice.bLength);

                printf("\nbDescriptorType = %d",ddevice.bDescriptorType);

                printf("\nbNumConfigurations =
%d",ddevice.bNumConfigurations);

                printf("\nbcdUSB = %d",ddevice.bcdUSB);

                printf("\nbDeviceClass = %d",ddevice.bDeviceClass);

                printf("\nbDeviceSubClass = %d",ddevice.bDeviceSubClass);

                printf("\nbDeviceProtocol = %d",ddevice.bDeviceProtocol);

                printf("\nbMaxPacketSize0 = %d",ddevice.bMaxPacketSize0);

                printf("\nidVendor = %d",ddevice.idVendor);

                printf("\nidProduct = %d",ddevice.idProduct);

                printf("\nbcdDevice = %d",ddevice.bcdDevice);

                printf("\niManufacturer = %d",ddevice.iManufacturer);

                printf("\niProduct = %d",ddevice.iProduct);

                printf("\niSerialNumber = %d",ddevice.iSerialNumber);

                no_of_config = ddevice.bNumConfigurations;

 

                for(dindex=0;dindex<no_of_config;dindex++)

                {

                        fprint_configuration(&config,found);

                }

                printf("\n");

 

 

        }

 

        libusb_free_device_list(list,1);

 

 

 

 

        /*deinitialize libusb*/

        libusb_exit(NULL);

 

 

        return 0;

}

 

 

fprint_configuration(struct libusb_config_descriptor *config,libusb_device
*found)

{

 

        int index;

        int no_of_interfaces;

        int cof;

        cof = libusb_get_active_config_descriptor(found,&config);

        printf("\n");

        printf("\n\nCONFIGURATION DESCRIPTOR");

printf("\nbLength = %d",config->bLength);

        printf("\nbDescriptorType = %d",config->bDescriptorType);

        printf("\niConfiguration = %d",config->iConfiguration);

        printf("\nwTotalLength = %d",config->wTotalLength);

        printf("\nbNumInterfaces = %d",config->bNumInterfaces);

        printf("\nbConfigurationValue = %d",config->bConfigurationValue);

        printf("\niConfiguration = %d",config->bmAttributes);

        printf("\nMaxPower = %d",config->MaxPower);

        printf("\nbNumInterfaces = %d",config->bNumInterfaces);

        no_of_interfaces = config->bNumInterfaces;

 

 

        for(index=0;index<no_of_interfaces;index++)

        {

                fprint_altsetting((config->interface));

                (config->interface)++;

        }

 

}

 

fprint_altsetting(struct libusb_interface *interface)

{

        int index;

        int no_of_altsettings;

 

        no_of_altsettings = interface->num_altsetting;

        for(index=0;index<no_of_altsettings;index++)

        {

                fprint_interface((interface->altsetting));

                (interface->altsetting)++;

        }

}

 

 

 

fprint_interface(struct libusb_interface_descriptor *interface)

{

 

        int index;

        int no_of_endpoints;

 

        printf("\n");

        printf("\n\nINTERFACE DESCRIPTOR");

        printf("\nbLength = %d",interface->bLength);

        printf("\nbInterfaceNumber = %d",interface->bInterfaceNumber);

        printf("\nbAlternateSetting = %d",interface->bAlternateSetting);

        printf("\nbNumEndpoints = %d",interface->bNumEndpoints);

        printf("\nbInterfaceClass = %d",interface->bInterfaceClass);

        printf("\nbInterfaceSubClass = %d",interface->bInterfaceSubClass);

        printf("\nbInterfaceProtocol = %d",interface->bInterfaceProtocol);

        printf("\niInterface = %d",interface->iInterface);

 

        no_of_endpoints=interface->bNumEndpoints;

 

        for(index=0;index<no_of_endpoints;index++)

        {

fprint_endpoint((interface->endpoint));

                (interface->endpoint)++;

        }

 

}

 

 

 

void fprint_endpoint(struct libusb_endpoint_descriptor *endpoint)

{

 

        printf("\n");

        printf("\n\nENDPOINT DESCRIPTOR");

        printf("\nbLength = %d",endpoint->bLength);

        printf("\nbDescriptorType = %d",endpoint->bDescriptorType);

        printf("\nbEndpointAddress =0x%02x",endpoint->bEndpointAddress);

        printf("\nbmAttributes = %d",endpoint->bmAttributes);

        printf("\nwMaxPacketSize = %d",endpoint->wMaxPacketSize);

        printf("\nbInterval = %d",endpoint->bInterval);

        printf("\nbRefresh = %d",endpoint->bRefresh);

        printf("\nbSynchAddress = %d",endpoint->bSynchAddress);

 

}

 

 

 

 

 

 

 

 

 

Compiling this program 

gcc –c usbdevicedetails.c

 

warnings are coming :

 

usbdevicedetails.c:106: warning: conflicting types for
âfprint_configurationâ

usbdevicedetails.c:4: warning: previous declaration of
âfprint_configurationâ was here

usbdevicedetails.c: In function âfprint_configurationâ:

usbdevicedetails.c:129: warning: passing argument 1 of âfprint_altsettingâ
discards qualifiers from pointer target type

usbdevicedetails.c: At top level:

usbdevicedetails.c:135: warning: conflicting types for âfprint_altsettingâ

usbdevicedetails.c:6: warning: previous declaration of âfprint_altsettingâ
was here

usbdevicedetails.c: In function âfprint_altsettingâ:

usbdevicedetails.c:143: warning: passing argument 1 of âfprint_interfaceâ
discards qualifiers from pointer target type

usbdevicedetails.c: At top level:

usbdevicedetails.c:150: warning: conflicting types for âfprint_interfaceâ

usbdevicedetails.c:5: warning: previous declaration of âfprint_interfaceâ
was here

usbdevicedetails.c: In function âfprint_interfaceâ:

usbdevicedetails.c:171: warning: passing argument 1 of âfprint_endpointâ
discards qualifiers from pointer target type

 

 

 

can you please give me the reason why is it??

Program is running fine

-- 
View this message in context: http://www.nabble.com/warnings-coming-on-implementing-libusb-tp22133247p22133247.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

Did you check that the data toggle is correct?

The USB hardware will ACK it even if the data toggle is wrong, and it
will probably get silently dropped by the firmware depending on the
implementation.

Mike 

> -----Original Message-----
> From: jeffp [mailto:jm...@ya...] 
> Sent: Friday, February 20, 2009 1:31 PM
> To: lib...@li...
> Subject: [Libusb-devel] can send only packets pne time
> 
> 
> I am using the synchronous bulk_transfer in libusb 1.0 
> (0.9.3) and RedHat
> Linux 2.6
> 
> I am having a strange problem where I reboot my device 
> (Digital Input to
> USB) streamer,  I can send 1 packet less than 512 bytes (USB 
> pkt size) but
> then cannot send any others. I do see the 2nd packet on the 
> sniffer but it
> never gets past the USB part (using logic scope) on the device.
> 
> I also see if I send bigger packets sometimes more packets 
> get through, and
> sometimes all of them make it but sometimes only a few to. 
> Again I see them
> all on the sniffer, but to not see them after the USB phy on 
> the device. I
> know this reeks of a device issue, but it works fine under 
> Windows with a
> non libusb driver so it would seem the device works correctly 
> except with
> libusb under Linux.
> 
> I think that I do see all expected ACKs on the sniffer.
> 
> The USB device is a fx2 processor which uses EZ-USB. The fx2 
> has an internal
> FIFO which feeds an external FIFO on the device whenever 
> there is data in
> the internal fx2 FIFO. It seems the pkts do not get into the 
> internal fx2
> FIFO (past the USB PHY).
> 
> We are stumped on what can be possibly happening, especially 
> since with
> Windows/non-libusb it works.
> I am not pointing fingers at libusb, but it is the only 
> difference. The
> applications on top of libusb or the Windows driver are the same.
> 
> Has anyone seen anything similar to this or have any ideas of 
> what may be
> going on or what I can check ? Unfortunately I have no 
> visibility inside the
> fx2.
> 
> 
> Thank You
> 
> Jeff Price
> 
> -- 
> View this message in context: 
> http://www.nabble.com/can-send-only-packets-pne-time-tp2212583
> 2p22125832.html
> Sent from the LibUSB Dev mailing list archive at Nabble.com.
> 
> 
> --------------------------------------------------------------
> ----------------
> Open Source Business Conference (OSBC), March 24-25, 2009, 
> San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing 
> the Enterprise
> -Strategies to boost innovation and cut costs with open 
> source participation
> -Receive a $600 discount off the registration fee with the 
> source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
> 

I am using the synchronous bulk_transfer in libusb 1.0 (0.9.3) and RedHat
Linux 2.6

I am having a strange problem where I reboot my device (Digital Input to
USB) streamer,  I can send 1 packet less than 512 bytes (USB pkt size) but
then cannot send any others. I do see the 2nd packet on the sniffer but it
never gets past the USB part (using logic scope) on the device.

I also see if I send bigger packets sometimes more packets get through, and
sometimes all of them make it but sometimes only a few to. Again I see them
all on the sniffer, but to not see them after the USB phy on the device. I
know this reeks of a device issue, but it works fine under Windows with a
non libusb driver so it would seem the device works correctly except with
libusb under Linux.

I think that I do see all expected ACKs on the sniffer.

The USB device is a fx2 processor which uses EZ-USB. The fx2 has an internal
FIFO which feeds an external FIFO on the device whenever there is data in
the internal fx2 FIFO. It seems the pkts do not get into the internal fx2
FIFO (past the USB PHY).

We are stumped on what can be possibly happening, especially since with
Windows/non-libusb it works.
I am not pointing fingers at libusb, but it is the only difference. The
applications on top of libusb or the Windows driver are the same.

Has anyone seen anything similar to this or have any ideas of what may be
going on or what I can check ? Unfortunately I have no visibility inside the
fx2.


Thank You

Jeff Price

-- 
View this message in context: http://www.nabble.com/can-send-only-packets-pne-time-tp22125832p22125832.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

On Wed, 18 Feb 2009, Nuno Santos wrote:

> I can show you my device side code. I'm in mysub/lufa list posting the 
> same problem and they say that is a host side problem.
> 
> I'm in between and completly crazy with this.
> 
> I have checked so many times that i'm getting crazy with this.
> 
> This is a full speed device:
> 
> Speed: 12Mb/s (full)
> USB Version:  2.00
> Device Class: 00(>ifc )
> Device Subclass: 00
> Device Protocol: 00
> Maximum Default Endpoint Size: 8
> Number of Configurations: 1
> Vendor Id: 03eb
> Product Id: 2048
> Revision Number:  0.00
> 
> Config Number: 1
>     Number of Interfaces: 2
>     Attributes: c0
>     MaxPower Needed: 100mA
> 
>     Interface Number: 0
>         Name: usbhid
>         Alternate Number: 0
>         Class: 03(HID  )
>         Sub Class: 02
>         Protocol: 01
>         Number of Endpoints: 1
> 
>             Endpoint Address: 81
>             Direction: in
>             Attribute: 3
>             Type: Int.
>             Max Packet Size: 8
>             Interval: 2ms
> 
>     Interface Number: 1
>         Name: (none)
>         Alternate Number: 0
>         Class: ff(vend.)
>         Sub Class: 00
>         Protocol: 00
>         Number of Endpoints: 1
> 
>             Endpoint Address: 82
>             Direction: in
>             Attribute: 3
>             Type: Int.
>             Max Packet Size: 32
>             Interval: 16ms
> 
> When I wrote this post I had 32 max length but I tried several times 
> with both sides with the same size, so its not the problem here.
> 
> The code I use in the device side to do it is like this:
> 
> volatile uint8_t frameData[FRAMESIZE] = 
> {255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255};void 
> 
> 
> sendFrame()
> {
> 
>     /* Check if the USB system is connected to a host */
>     if (USB_IsConnected)
>     {
>         Endpoint_SelectEndpoint(RAW_IN_EPNUM);           
>        
>         // Check if endpoint is ready to be written to
>         if (Endpoint_ReadWriteAllowed())
>         {
>             Endpoint_Write_Stream_LE(&frameData, sizeof(frameData));
>             Endpoint_ClearCurrentBank();
>         }   
>     }
> }

If you use a Linux host then you can use usbmon to find out exactly 
what data is getting sent.

Alan Stern

I can show you my device side code. I'm in mysub/lufa list posting the 
same problem and they say that is a host side problem.

I'm in between and completly crazy with this.

I have checked so many times that i'm getting crazy with this.

This is a full speed device:

Speed: 12Mb/s (full)
USB Version:  2.00
Device Class: 00(>ifc )
Device Subclass: 00
Device Protocol: 00
Maximum Default Endpoint Size: 8
Number of Configurations: 1
Vendor Id: 03eb
Product Id: 2048
Revision Number:  0.00

Config Number: 1
    Number of Interfaces: 2
    Attributes: c0
    MaxPower Needed: 100mA

    Interface Number: 0
        Name: usbhid
        Alternate Number: 0
        Class: 03(HID  )
        Sub Class: 02
        Protocol: 01
        Number of Endpoints: 1

            Endpoint Address: 81
            Direction: in
            Attribute: 3
            Type: Int.
            Max Packet Size: 8
            Interval: 2ms

    Interface Number: 1
        Name: (none)
        Alternate Number: 0
        Class: ff(vend.)
        Sub Class: 00
        Protocol: 00
        Number of Endpoints: 1

            Endpoint Address: 82
            Direction: in
            Attribute: 3
            Type: Int.
            Max Packet Size: 32
            Interval: 16ms

When I wrote this post I had 32 max length but I tried several times 
with both sides with the same size, so its not the problem here.

The code I use in the device side to do it is like this:

volatile uint8_t frameData[FRAMESIZE] = 
{255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255};void 


sendFrame()
{

    /* Check if the USB system is connected to a host */
    if (USB_IsConnected)
    {
        Endpoint_SelectEndpoint(RAW_IN_EPNUM);           
       
        // Check if endpoint is ready to be written to
        if (Endpoint_ReadWriteAllowed())
        {
            Endpoint_Write_Stream_LE(&frameData, sizeof(frameData));
            Endpoint_ClearCurrentBank();
        }   
    }
}

Thx

Nuno

Alan Stern wrote:
> On Wed, 18 Feb 2009, Nuno Santos wrote:
>
>   
>> Hi,
>>
>> I'm sending over an endpoint with a max packet size of 32, 16 bytes of 
>> data (each by is 0xff).
>>
>> Endpoint Address: 82
>>             Direction: in
>>             Attribute: 3
>>             Type: Int.
>>             Max Packet Size: 32
>>             Interval: 16ms
>>
>> But, after the request the result is:
>>
>> 255 255 255 255 255 255 255 255 0 0 0 0 0 0 0 0 end
>>     
>
>   
>> I'm stucked in this problem for a long time and if there any problem 
>> with the request I can't see it. Do you people see anything missing here?
>>     
>
> There's the obvious possibility: The device really is sending 8 bytes 
> instead of 16.  Or 16 bytes of which only 8 contain 0xff.
>
> Alan Stern
>
>