Re: [libusb] Issue with raspberry pi and libusb_bulk_transfer if buffer size is too big

[David L. <dav...@le...>]

Thanks for the clarification on the transactions logic.

I still dont understand why I dont receive all data when I specifiy that the receive buffer has a size > 0x4000 on the raspberry.

I made a small change to work around it, I just find the issue weird

	int lLen = 0;
	libusb_bulk_transfer( mHandle, aEndPoint | LIBUSB_ENDPOINT_IN, aData, aSize>0x4000? 0x4000 : aSize, &lLen, mReadTimeout );

	if( lLen == 0x4000 )
	{
	    libusb_bulk_transfer( mHandle, aEndPoint | LIBUSB_ENDPOINT_IN, aData+0x4000, aSize - 0x4000, &lLen, mReadTimeout );
	}

-----Message d'origine-----
De : Tim Roberts <ti...@pr...> 
Envoyé : 26 juillet 2019 18:49
À : lib...@li...
Objet : Re: [libusb] Issue with raspberry pi and libusb_bulk_transfer if buffer size is too big

David Levy wrote:
>
> Our device does not send a short packet when the transfer is complete but the driver probably does. We just provide the size of the data to send.

_usb_device_send_data handles it.


> And the biggest transfer is actually 0x407c bytes I forgot about the headers. So its not a multiple of packet size.

That's fine.   It's just important to understand how the transactions actually flow over the wire.  The USB engine on your MQX4 will send things out 64 bytes at a time.  So, this transfer will be sent out as
257 packets of 64 bytes, plus one packet of 60 bytes.  If your driver does a read of, for example, 0x5000 bytes. that one read will keep gathering packets until the short one, at which point the transfer ends.  If you sent a read of 0x2000 bytes, you would collect the first
128 packets, then the request would be completed.  The device doesn't know that; it only knows that it has stopped seeing reads.  If sent another read of 0x2000 bytes, you would collect the next 128 packets, and the request would be completed.  The device still has more.  If you sent another read of 0x2000 bytes, you'd collect the last two packets, one of 64, one of 60, and the request would complete because of the short packet.

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