Bare Minimum Isochronous Transfer using SPP

The test software running on PC from my first post was using the libusb driver.

The communication to isochronous usb device was possible,
but there have been a few issues.

1st and biggest problem:

   I was not able to read data continuously without a pause of about 300ms
   between two data requests !


So i decided to switch over to mchp driver even if I read some comments
from xiaofan, that isochronous is possibly not doable with mchp driver.

I modified my "minimum PDFSUSBdemo" for use to read and write the EP1 pipes.
(see attachment if interested)


[&:][:@] SADLY THE RESULT IS THE SAME [&:][:@][&:][:@]

I'm not really able to read or write continuously.
The only thing I can counton is the "Invalid Handle" error.

Some of my thoughts about that:

1.
It seems to depend on the number of requested bytes as well as of time between the calls.
I do not really understand why some combinations run well and others not at all.
Requests for some numbers of data are not possible even not at first time.

2.
If I understand (a little bit ) the USB2.0 specification, the packet size
in the endpoint descriptor is primary used to reserve bandwith on the bus
and to determine how many bytes the device buffers can handle in one transaction.
Correct ?

3.
Watching my scope, I recognized that there may be more than one packet
transfered in a 1ms frame, if big amount of data has to be transfered.

i.e. The time for a transfer does not increase further if transfers are bigger than 32kB.
(partially two packets are transfered in 1ms then)

4.
When the communication breaks, it seems that it happens on PC side
(I usually still can see the read clocks at the Streaming-Parallel-Port)


5.
How to initiate a (fast) continuous data stream ?


Anybody has got some ideas ???

In my project of isochronous sample/recording I employed both cyusb and usbsamp drivers (the idea of having another struggle with libusb is too scaring for me).
 
The differences between my project and yours are only the source/sink of data (ADC vs SPP) and the different driver, but from your posts I see you have resolved the SPP issue.
 
In your case (reading) the problem is much alike my sampling.
 
On PIC side I had problems only about synchronizing data producing and data transmitting, but that is another story. The packet trasmission is accomplished sending continously a packet( setting address, toggling UOWN )if SIE is not busy.
 
On PC side (omitting the problem of threading and havig a non blocking streaming) I had at least 2 buffers with overlapped I/O on each of them, and requests tipically of 8 packets for each request. (Cbuilder and c#)
 
At last everything worked fine with modest speeds (50 kHz), the bottleneck being the sampling/recording routine duration and not USB speed.
 
I had weird problems, never resolved, in loopback tests (ok on a PC, ko on another, OK on a hub,KO on another,ok with cyusb, bad with usbsamp).
 
If you outline a bit your system with more detail,I'll try to be of more help.
 
 Anyway trying ubsamp with crevars modifications would be a good idea.
 
And about isochronous Tsuneo is *the* source since when he navigated far from Microchip forum.

By the way, you seem to use Visual C++ with libusb-win32. I've heard people having problem with it. You might give MinGW a try, it works well with libusb-win32 and I always use it with libusb-win32.

Still try to figure out things about this "+/-USBD_ISO_START_FRAME_RANGE"

In the meanwhile post the protocol for a "USBD_STATUS_BAD_START_FRAME"

Maybe one of you already could point me to the problem

[10216755 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
 [10216755 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=86830008, IRQL=0
 [10216755 ms]  >>>  URB 54 going down  >>> 
 -- URB_FUNCTION_ISOCH_TRANSFER:
   PipeHandle           = 8730a604 [endpoint 0x00000081]
   TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
   TransferBufferLength = 00000080
   TransferBuffer       = 00000000
   TransferBufferMDL    = 866fc3d8
   StartFrame           = 00000000
   NumberOfPackets      = 00000001
   IsoPacket[0].Offset = 0
   IsoPacket[0].Length = 0
   UrbLink              = 00000000
 [10216761 ms] UsbSnoop - MyInternalIOCTLCompletion(b676c126) : fido=86979020, Irp=86830008, Context=868eebc8, IRQL=2
 [10216761 ms]  <<<  URB 54 coming back  <<< 
 -- URB_FUNCTION_ISOCH_TRANSFER:
   PipeHandle           = 8730a604 [endpoint 0x00000081]
   TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
   TransferBufferLength = 00000080
   TransferBuffer       = 00000000
   TransferBufferMDL    = 866fc3d8
   StartFrame           = 009bf915
   NumberOfPackets      = 00000001
   ErrorCount           = 00000000
   IsoPacket[0].Offset = 0
   IsoPacket[0].Length = 128
   IsoPacket[0].Status = 00000000
     00000000: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
     00000010: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
     00000020: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
     00000030: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
     00000040: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
     00000050: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
     00000060: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
     00000070: 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04 04
   UrbLink              = 00000000
 [10216771 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
 [10216771 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=86830008, IRQL=0
 [10216771 ms]  >>>  URB 55 going down  >>> 
 -- URB_FUNCTION_ISOCH_TRANSFER:
   PipeHandle           = 8730a604 [endpoint 0x00000081]
   TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
   TransferBufferLength = 00000080
   TransferBuffer       = 00000000
   TransferBufferMDL    = 866fc3d8
   StartFrame           = 00000000
   NumberOfPackets      = 00000001
   IsoPacket[0].Offset = 0
   IsoPacket[0].Length = 0
   UrbLink              = 00000000
 [10216771 ms] UsbSnoop - MyInternalIOCTLCompletion(b676c126) : fido=86979020, Irp=86830008, Context=868eebc8, IRQL=2
 [10216771 ms]  <<<  URB 55 coming back  <<< 
 -- URB_FUNCTION_ISOCH_TRANSFER:
   PipeHandle           = 8730a604 [endpoint 0x00000081]
   TransferFlags        = 00000007 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK, USBD_START_ISO_TRANSFER_ASAP
   TransferBufferLength = 00000000
   TransferBuffer       = 00000000
   TransferBufferMDL    = 866fc3d8
   StartFrame           = 009bf916
   NumberOfPackets      = 00000001
   ErrorCount           = 00000001
   IsoPacket[0].Offset = 0
   IsoPacket[0].Length = 0
   IsoPacket[0].Status = c0000a00
   UrbLink              = 00000000
 [10220236 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL
 [10220236 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=87123888, IRQL=0
 

USBD_STATUS_BUFFER_OVERRUN (0xc000000c)

Not just for isoc, for all types of IN transfers, USBDI requires a buffer of "expected size" at each IN request call (URB: USB Request Block). When the incoming bytes from device exceed this expected size, USBD_STATUS_BUFFER_OVERRUN occurs.

For isoc transfer, you can specify multiple packets at a single URB. USBDI checks each packet size for buffer overrun, not the entire size. Then, if you take variable packet-size approach to represent fractional sampling rate, you have to specify possible max packet size to the URB.

"USB Isochronous Transfer" on MSDN
http://msdn.microsoft.com/en-us/library/ms790482.aspx


USBD_STATUS_BAD_START_FRAME (0xc0000a00)

I think the issue with the "USBD_STATUS_BAD_START_FRAME"
is described in MS presentation

Umm... The MS presentation is related to the error at the point that both cases are caused by USBD_START_ISO_TRANSFER_ASAP flag. As the presentation shows, MS suddenly changed (or fixed) the operation of USBD_START_ISO_TRANSFER_ASAP flag on XP. Walter Oney (the author of famous "Windows Driver Model") explains about the history, the status on XP and workaround on this topic.

"Anomalous behavior of USBD_START_ISO_TRANSFER_ASAP flag in XP" on microsoft.public.development.device.drivers
http://groups.google.com/group/microsoft.public.development.device.drivers/browse_thread/thread/394f5f24e6dfbfe0/1237cd0aafd50423?hl=en

Tsuneo

chinzei,

thanks a lot for your assistance !

Unfortunately I'm not a skilled windows programmer.
If I hear about drivers or threads, dll's and such things,
I run away .
Usually I write small applications to test the hardware only.
(The "real" application must must be written by someone else [&:])
 

Working on the current issue is based more on intuition rather than
knowledge. But, maybe I found a solution. [8D]

I tried the "workaround" described in USBdrv-tips2.ppt

Potential Workarounds
reset the pipe before sending every URB
...

The libUSB driver provides a function to reset an endpoint that seems to work:
int usb_resetep(usb_dev_handle *dev, unsigned int ep);

Hope that my first impression will persist during a few tests

Is it working now? If yes, maybe you want to attach the working code. Thanks.

OK, here are new versions of firmware an test code (libUSB)

<edit> please change in "usb_descriptors.c"

     ISO_EP_SIZE,0x01,                //size
 >>
     ISO_EP_SIZE,                //size
     ISO_EP_SIZE/256,            //size

1. my English dictionary (the one I got "edacious" from )
gave me 4 translations for this word.

edacious  adj. rare

gierig - avido
gefräßig - vorace
verzehrend - edace adj. anche  [fig.] raro
unersättlich - insaziabile

2. I'm not a professor - staff engineer only .
  (therefore sometimes pick improper words from dictionaries )


<edit> ... just noticed the "rare" 

Galleries HardWare|SoftWare|PIC USB related web sites

wonderful