|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
|
|
Libusb 0.1 questionHi,
I'm performing bulk transfers on libusb 0.1 and the packets are coming in an intercaled order. My packets are number and instead of coming in order they appear like this: 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 000 000 001 001 002 002 003 003 004 004 005 005 006 006 007 007 008 008 009 009 010 010 011 011 012 012 013 013 014 014 015 015 Why is this happening? Any tips? Thanks, Nuno -- *Nuno Santos* R&D Assistant displax *A REGISTERED TRADEMARK OF EDIGMA GROUP* we provide local support and are present in * EUROPE **N&S AMERICA** M.EAST **ASIA** WEB - ** *www.displax.com <http://www.displax.com> *E-MAIL - *displax@... <mailto:displax@...>** *DISPLAX _ INTERACTIVE SYSTEMS* CENTRO DE NEGOCIOS EMPRESARIAIS PARQUE IND. ADAÚFE , LT C3 4710 - 167 BRAGA PORTUGAL *TEL - *+351 253 265 506 *FAX - *+351 253 265 507** ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionOn Thu, 8 Oct 2009, Nuno Santos wrote:
> Hi, > > I'm performing bulk transfers on libusb 0.1 and the packets are coming > in an intercaled order. My packets are number and instead of coming in > order they appear like this: > > 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 > 007 007 007 007 007 007 007 007 007 007 007 007 007 007 > 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 > 007 007 007 007 007 007 007 007 007 007 007 007 007 007 > 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 > 006 006 006 006 006 006 006 006 006 006 006 006 006 006 > 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 > 006 006 006 006 006 006 006 006 006 006 006 006 006 006 > 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 > 009 009 009 009 009 009 009 009 009 009 009 009 009 009 > 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 > 009 009 009 009 009 009 009 009 009 009 009 009 009 009 > 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 > 008 008 008 008 008 008 008 008 008 008 008 008 008 008 > 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 > 008 008 008 008 008 008 008 008 008 008 008 008 008 008 > 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 > 011 011 011 011 011 011 011 011 011 011 011 011 011 011 > 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 > 011 011 011 011 011 011 011 011 011 011 011 011 011 011 > 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 > 010 010 010 010 010 010 010 010 010 010 010 010 010 010 > 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 > 010 010 010 010 010 010 010 010 010 010 010 010 010 010 > 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 > 013 013 013 013 013 013 013 013 013 013 013 013 013 013 > 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 > 013 013 013 013 013 013 013 013 013 013 013 013 013 013 > 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 > 012 012 012 012 012 012 012 012 012 012 012 012 012 012 > 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 > 012 012 012 012 012 012 012 012 012 012 012 012 012 012 > 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 > 015 015 015 015 015 015 015 015 015 015 015 015 015 015 > 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 > 015 015 015 015 015 015 015 015 015 015 015 015 015 015 > 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 > 014 014 014 014 014 014 014 014 014 014 014 014 014 014 > 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 > 014 014 014 014 014 014 014 014 014 014 014 014 014 014 > 000 000 001 001 002 002 003 003 004 004 005 005 006 006 007 007 008 008 > 009 009 010 010 011 011 012 012 013 013 014 014 015 015 > > Why is this happening? If packets arrive out of order, it must be because they were transmitted out of order. The USB cable can't rearrange packets. Alan Stern ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionHi Alan,
I'm sorry to tell you but the packets are being sent in order! :) I'm already working on this firmware on several months and I can assure you that. I was using libusb 1.0 which now I can see that really is much better than 0.1 I'm only doing this downgrade because I'm developing a Qt application to run in windows and linux. Any more tips? Thanks, Nuno Alan Stern wrote: > On Thu, 8 Oct 2009, Nuno Santos wrote: > > >> Hi, >> >> I'm performing bulk transfers on libusb 0.1 and the packets are coming >> in an intercaled order. My packets are number and instead of coming in >> order they appear like this: >> >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 000 000 001 001 002 002 003 003 004 004 005 005 006 006 007 007 008 008 >> 009 009 010 010 011 011 012 012 013 013 014 014 015 015 >> >> Why is this happening? >> > > If packets arrive out of order, it must be because they were > transmitted out of order. The USB cable can't rearrange packets. > > Alan Stern > > -- *Nuno Santos* R&D Assistant displax *A REGISTERED TRADEMARK OF EDIGMA GROUP* we provide local support and are present in * EUROPE **N&S AMERICA** M.EAST **ASIA** WEB - ** *www.displax.com <http://www.displax.com> *E-MAIL - *displax@... <mailto:displax@...>** *DISPLAX _ INTERACTIVE SYSTEMS* CENTRO DE NEGOCIOS EMPRESARIAIS PARQUE IND. ADAÚFE , LT C3 4710 - 167 BRAGA PORTUGAL *TEL - *+351 253 265 506 *FAX - *+351 253 265 507** ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionWell, the other possibility (and easier one to troubleshoot or rule out) is
if they're being PRINTED out of order. Perhaps a mistake in a circular buffer (been there). You're probably going to have to post more information. How small can you make the host-side code and still duplicate the problem? This looks like 10.5 64-byte packets, but maybe I miscounted? That last partial packet seems to be very different, yet have related numbers, so it'd be nice to actually verify that the code receiving it is dumping it as it really is on the wire... Is this on Linux? Does it already work on another platform? Michael -----Original Message----- From: Nuno Santos [mailto:nsantos@...] Sent: Thursday, October 08, 2009 10:16 AM To: libusb-devel@... Subject: Re: [Libusb-devel] Libusb 0.1 question Hi Alan, I'm sorry to tell you but the packets are being sent in order! :) I'm already working on this firmware on several months and I can assure you that. I was using libusb 1.0 which now I can see that really is much better than 0.1 I'm only doing this downgrade because I'm developing a Qt application to run in windows and linux. Any more tips? Thanks, Nuno Alan Stern wrote: > On Thu, 8 Oct 2009, Nuno Santos wrote: > > >> Hi, >> >> I'm performing bulk transfers on libusb 0.1 and the packets are coming >> in an intercaled order. My packets are number and instead of coming in >> order they appear like this: >> >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 007 007 007 007 007 007 007 007 007 007 007 007 007 007 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 006 006 006 006 006 006 006 006 006 006 006 006 006 006 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 009 009 009 009 009 009 009 009 009 009 009 009 009 009 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 008 008 008 008 008 008 008 008 008 008 008 008 008 008 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 011 011 011 011 011 011 011 011 011 011 011 011 011 011 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 010 010 010 010 010 010 010 010 010 010 010 010 010 010 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 013 013 013 013 013 013 013 013 013 013 013 013 013 013 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 012 012 012 012 012 012 012 012 012 012 012 012 012 012 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 015 015 015 015 015 015 015 015 015 015 015 015 015 015 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 014 014 014 014 014 014 014 014 014 014 014 014 014 014 >> 000 000 001 001 002 002 003 003 004 004 005 005 006 006 007 007 008 008 >> 009 009 010 010 011 011 012 012 013 013 014 014 015 015 >> >> Why is this happening? >> > > If packets arrive out of order, it must be because they were > transmitted out of order. The USB cable can't rearrange packets. > > Alan Stern > > -- *Nuno Santos* R&D Assistant ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionMichael Plante wrote:
> Well, the other possibility (and easier one to troubleshoot or rule > out) is if they're being PRINTED out of order. Maybe usbmon can help too? //Peter ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 question
Hi,
The code is what I usually do: This goes into a thread void USB::captureData() { int j; while(1) { getData(); } } And then: void USB::getData() { int j,readBytes = 0; readBytes += usb_bulk_read(devHandle, 0x82, (char *) buffer0, sizeof (unsigned char) * 64, 0); for (j=0; 64 j++) { if (j%32==0) puts(""); printf("%03d ", buffer[j]); } } In order to overcome this problem for a while I had to do this stupid thing: void USB::getData() { int j,b,readBytes = 0; readBytes += usb_bulk_read(devHandle, 0x82, (char *) buffer0, sizeof (unsigned char) * 64, 0); for (b=1;b>=0;b--) { if (b==1) memcpy(buffer,buffer1,sizeof(unsigned char) * 64); if (b==0) memcpy(buffer,buffer0,sizeof(unsigned char) * 64); for (j=0; 64 j++) { if (j%32==0) puts(""); printf("%03d ", buffer[j]); } } } Now I'm going to test this in windows but it will take a while. Other solution is to keep the linux version using 1.0 (which is much better and also supports isochronous) and make the windows version use the new WinUSB API. Well, this is not a big deal. I was just curious if it was a known problem. I just remembered that I have double banking on my endpoint configuration, so I changed it to single bank and now it doesnt work in this 0.1 app however it is working in 1.0 in the same way. Best regards, Nuno Michael Plante wrote: Well, the other possibility (and easier one to troubleshoot or rule out) is if they're being PRINTED out of order. Perhaps a mistake in a circular buffer (been there). You're probably going to have to post more information. How small can you make the host-side code and still duplicate the problem? This looks like 10.5 64-byte packets, but maybe I miscounted? That last partial packet seems to be very different, yet have related numbers, so it'd be nice to actually verify that the code receiving it is dumping it as it really is on the wire... Is this on Linux? Does it already work on another platform? Michael -----Original Message----- From: Nuno Santos [nsantos@...] Sent: Thursday, October 08, 2009 10:16 AM To: libusb-devel@... Subject: Re: [Libusb-devel] Libusb 0.1 question Hi Alan, I'm sorry to tell you but the packets are being sent in order! :) I'm already working on this firmware on several months and I can assure you that. I was using libusb 1.0 which now I can see that really is much better than 0.1 I'm only doing this downgrade because I'm developing a Qt application to run in windows and linux. Any more tips? Thanks, Nuno Alan Stern wrote: ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionNuno Santos wrote:
> Hi, > > The code is what I usually do: > > This goes into a thread You aren't checking the number of bytes actually transferred, and you are printing the entire buffer every time. So, chances are, the output you posted to this list is not reflective of what libusb actually thought happened. Daniel ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionHi Daniel,
Actually I had that check, however I have not included it that in the sample posted in the last email. You can be sure that the results posted were not influenced by that! With my best regards, Nuno Daniel Drake wrote: > Nuno Santos wrote: >> Hi, >> >> The code is what I usually do: >> >> This goes into a thread > > You aren't checking the number of bytes actually transferred, and you > are printing the entire buffer every time. So, chances are, the output > you posted to this list is not reflective of what libusb actually > thought happened. > > Daniel > -- *Nuno Santos* R&D Assistant displax *A REGISTERED TRADEMARK OF EDIGMA GROUP* we provide local support and are present in * EUROPE **N&S AMERICA** M.EAST **ASIA** WEB - ** *www.displax.com <http://www.displax.com> *E-MAIL - *displax@... <mailto:displax@...>** *DISPLAX _ INTERACTIVE SYSTEMS* CENTRO DE NEGOCIOS EMPRESARIAIS PARQUE IND. ADAÚFE , LT C3 4710 - 167 BRAGA PORTUGAL *TEL - *+351 253 265 506 *FAX - *+351 253 265 507** ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionNuno,
The question arises as to what else has been changed (for example, is this the only thread accessing the device, is there more than one buffer (buffer0 vs buffer), is this the only loop in getData (+= seems odd otherwise), is that the only "for" loop termination condition, etc.). When I asked for minimal code, I meant something that would still compile and reproduce the problem. But maybe we should take a different approach. Have you tried usbmon, like Peter suggested? Michael -----Original Message----- From: Nuno Santos [mailto:nsantos@...] Sent: Thursday, October 08, 2009 12:54 PM To: libusb-devel@... Subject: Re: [Libusb-devel] Libusb 0.1 question Hi Daniel, Actually I had that check, however I have not included it that in the sample posted in the last email. You can be sure that the results posted were not influenced by that! With my best regards, Nuno Daniel Drake wrote: > Nuno Santos wrote: >> Hi, >> >> The code is what I usually do: >> >> This goes into a thread > > You aren't checking the number of bytes actually transferred, and you > are printing the entire buffer every time. So, chances are, the output > you posted to this list is not reflective of what libusb actually > thought happened. > > Daniel > -- *Nuno Santos* R&D Assistant displax *A REGISTERED TRADEMARK OF EDIGMA GROUP* we provide local support and are present in * EUROPE **N&S AMERICA** M.EAST **ASIA** WEB - ** *www.displax.com <http://www.displax.com> *E-MAIL - *displax@... <mailto:displax@...>** *DISPLAX _ INTERACTIVE SYSTEMS* CENTRO DE NEGOCIOS EMPRESARIAIS PARQUE IND. ADAÚFE , LT C3 4710 - 167 BRAGA PORTUGAL *TEL - *+351 253 265 506 *FAX - *+351 253 265 507** ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
|
|
Re: Libusb 0.1 questionNuno Santos wrote:
> > The code is what I usually do: > > This goes into a thread Exactly one thread? Or are there multiple threads? Libusb 0.1 is not thread-safe. If you submit multiple requests on multiple threads, there is no telling what data will be returned to which call. > void USB::getData() > { > int j,readBytes = 0; > readBytes += usb_bulk_read(devHandle, 0x82, (char *) buffer0, > sizeof (unsigned char) * 64, 0); Are you aware that sizeof(unsigned char) is mandated by the standards to be 1, always? The other things I was going to point out have already been pointed out. There are several typos in this code, so this cannot be your exact code. Can you cut-and-paste the exact code that you are using? > Well, this is not a big deal. I was just curious if it was a known > problem. You need to rest assured that this is YOUR problem. It's a problem in your app, or in your firmware. There is simply no place within the USB stack where this kind of rearrangement CAN occur. It cannot happen. -- Tim Roberts, timr@... Providenza & Boekelheide, Inc. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libusb-devel mailing list Libusb-devel@... https://lists.sourceforge.net/lists/listinfo/libusb-devel |
| Free embeddable forum powered by Nabble | Forum Help |