vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
Bare Minimum Isochronous Transfer using SPP
I'm interested in using the Streaming-Parallel-Port for reading data from an USB device. Like xiaofan said in his thread: Bare Minimum Isochronous Transfer Generic USB Device Example ORIGINAL: xiaofan I've searched the forum for a generic isoc transfer based example code but to no avail. I've done a bare minimum Isochronous Transfer Generic USB device port for PICKit 2 modified from the Microchip generic USB example. I have not yet fully understood the frame code yet so I choose the simplest method without using Ping-Pong buffer. So it is not really useful at all but just a step in the long learning process. The same to me.   (not fully understand ...) Regardless of that, I tried to setup a minimum SPP mode and post the results (so far) here. Maybe there are some of you out there, don't know how to start and also don't find any examples. I used the MCHP USB framework 2.3 for the firmware, and the project should be located like the original demos of that framework. ("USB Device - ISO_SPP" or like this) The project is configured for a PIC18F4550 on an old PICDEM USB demo board (the really old one made for PIC16C7x5 controllers) The test software on PC side is based on xiaofan's console example and requires the libusb driver. Hopefully this is useful for anybody and at best there will come in some improvements ((( why we need Sleep() in the test loops ?, some documentation for "libusb" i.e. the 32640 bytes limit for usb_submit_async(...) ... ))) <edit> typos <edit2> Please use attachments found at post #16 (reading continuous without delays)
post edited by vloki - 2011/03/07 08:08:41
Attached Image(s)
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/09 05:34:23
(permalink)
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 ???
Attached Image(s)
|
crevars
Starting Member
- Total Posts : 50
- Reward points : 0
- Joined: 2005/10/06 07:44:56
- Location: Odyssee-systemes, France
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/09 10:37:53
(permalink)
I was not able to read data continuously without a pause of about 300ms between two data requests ! Hi, I don't know how the libusb driver handles the isochronous reads. However, in general, if you want to have one isochronous transaction on every single frame, you have to ask the driver to read a pretty big amount of data (let's says 20 times the isochronous endpoint buffer size) and you need to be sure that the driver will get a new read request as soon as the previous one is finished (by sending a read request before the previous one if the driver is able to handle pending io requests). I did this in a previous project using usbsamp (a demo driver included in the WDK). You can also read this: http://forum.microchip.com/tm.aspx?m=295708&mpage=1 I hope this will help you. Regards, Franck.
post edited by crevars - 2008/10/09 10:48:41
|
stefanopod
Super Member
- Total Posts : 1285
- Reward points : 0
- Joined: 2007/06/25 02:33:59
- Location: Bologna,Italy
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/09 13:14:44
(permalink)
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.
|
xiaofan
Super Member
- Total Posts : 6247
- Reward points : 0
- Joined: 2005/04/14 07:05:25
- Location: Singapore
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/09 15:54:19
(permalink)
From what I read, cyusb is a very good driver and you may want to try it. You can also try usbsamp. There are very few examples with libusb-win32 and isochronous transfer and I actually do not quite understand how it works (asynchronous I/O). Last time I posted the question in the mailing list and nobody answered me. If you have access to Linux, then you may want to try out libusb 1.0. It is supposed to support isochronous transfer well. The old libusb-0.1 under Linux does not support isochronous transfer. When I have sometime, I will try out your project.
|
xiaofan
Super Member
- Total Posts : 6247
- Reward points : 0
- Joined: 2005/04/14 07:05:25
- Location: Singapore
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/09 16:01:37
(permalink)
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.
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/10 02:51:57
(permalink)
Frank, Stefano & Xiaofan, many thanks for your suggestions. Before I switch to another driver again I decided to try finding out whats going wrong exactly. The usb sniffer software (demo) I used in the past was a expired and I had to find a new one. (Now use open source SniffUSB  ) The first issue I figured out is the USBD_STATUS_BUFFER_OVERRUN error. Because I use the SPP the PIC always seems to read or write complete packages. (I can see it, monitoring the RD and WR clocks of SPP) If the request does not fit to this size, naturally a buffer overrun occurs A bit strange is that this error does not end up with an error at the application mandatory. If the request is less than packet size, the pipe handle always gets lost. If the request is more than x*packet size, the handle keeps ok and the application seems to get the requested number of data. [8D] Below I post the sniffer protocol for a 129 byte in transfer at an endpoint size of 128: [4832887 ms] UsbSnoop - FilterDispatchAny(b676bfd2) : IRP_MJ_INTERNAL_DEVICE_CONTROL [4832887 ms] UsbSnoop - FdoHookDispatchInternalIoctl(b676c1ea) : fdo=86858598, Irp=86904508, IRQL=0 [4832888 ms] >>> URB 39 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 = 00000081 TransferBuffer = 00000000 TransferBufferMDL = 868f6988 StartFrame = 00000000 NumberOfPackets = 00000002 IsoPacket[0].Offset = 0 IsoPacket[0].Length = 0 IsoPacket[1].Offset = 128 IsoPacket[1].Length = 0 UrbLink = 00000000 [4832894 ms] UsbSnoop - MyInternalIOCTLCompletion(b676c126) : fido=86979020, Irp=86904508, Context=868eebc8, IRQL=2 [4832895 ms] <<< URB 39 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 = 00000081 TransferBuffer = 00000000 TransferBufferMDL = 868f6988 StartFrame = 0049ce88 NumberOfPackets = 00000002 ErrorCount = 00000001 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 IsoPacket[1].Offset = 128 IsoPacket[1].Length = 1 IsoPacket[1].Status = c000000c 00000000: 04 UrbLink = 00000000
Seems to be easy to omit this issue using always fitting numbers The next error I will try to analyze will be: USBD_STATUS_BAD_START_FRAME
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/10 03:14:02
(permalink)
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
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/10 05:21:18
(permalink)
I think the issue with the "USBD_STATUS_BAD_START_FRAME" is described in MS presentation USBdrv-tips2.ppt
|
chinzei
Super Member
- Total Posts : 2250
- Reward points : 0
- Joined: 2003/11/07 12:39:02
- Location: Tokyo, Japan
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/10 06:56:05
(permalink)
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
Super Member
- Total Posts : 2250
- Reward points : 0
- Joined: 2003/11/07 12:39:02
- Location: Tokyo, Japan
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/10 22:51:00
(permalink)
For USBD_START_ISO_TRANSFER_ASAP problem, it may be better to explain briefly the background of this issue. For continuous data streaming over USB (on either isoc or bulk), we have to put Read/Write call repeatedly on our host app. In this case, multiple OVERLAPPED Read/Write calls are issued simultaneously, to ensure gapless transfer. These multiple calls are stored to the device request queue, executed by the device driver one by one sequentially. When a call completes, the host app fills up another call, to keep the device queue populated. In this way, seamless transfer is maintained. Before XP, USBD_START_ISO_TRANSFER_ASAP flag works when the device request is executed; it fills the start frame automatically to the next frame of the last device request. After XP, USBD_START_ISO_TRANSFER_ASAP flag works when the device request is queued; it fills the start frame to the current one when the request is issued. As most of isoc applications have depended to the former function of USBD_START_ISO_TRANSFER_ASAP, many applications were forced update on XP. Some apps aren't updated yet. Tsuneo
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/13 02:12:02
(permalink)
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
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/13 04:49:24
(permalink)
   I'm an idiot   After doing some more tests, it is clear now that no endpoint reset is needed. If I never did change xiaofans example test code I would have had less trouble. I didn't understand the conceptwith the multiple context and multiple URBs and destroyed the sequence with my modifications. [:@][:@][:@] Thanks again chinzei and crevars, even if i did not understand your explanations from the beginning, at the end they pointed me the right way.
|
xiaofan
Super Member
- Total Posts : 6247
- Reward points : 0
- Joined: 2005/04/14 07:05:25
- Location: Singapore
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/13 06:15:21
(permalink)
Is it working now? If yes, maybe you want to attach the working code. Thanks.
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/13 06:21:41
(permalink)
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2008/10/13 23:38:00
(permalink)
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
post edited by vloki - 2008/10/13 23:56:50
|
stefanopod
Super Member
- Total Posts : 1285
- Reward points : 0
- Joined: 2007/06/25 02:33:59
- Location: Bologna,Italy
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2009/01/14 04:17:29
(permalink)
Hi vloki, I downloaded your code and I met this remark: do not add time edacious functions !!! I couldn't find "edacious" in any english dictionary. My only clue is "edere" in latin for eating, that is edacious=hungry. I know you are a professor, but your speech has to be easy; you aren't a professor for professors, I guess. This point omitted, your experiment is very interesting.
|
vloki
Jo, alla!
- Total Posts : 6815
- Reward points : 0
- Joined: 2007/10/15 00:51:49
- Location: Germany
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2009/01/14 05:06:04
(permalink)
  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
post edited by vloki - 2010/07/11 05:45:04
|
stefanopod
Super Member
- Total Posts : 1285
- Reward points : 0
- Joined: 2007/06/25 02:33:59
- Location: Bologna,Italy
- Status: offline
RE: Bare Minimum Isochronous Transfer using SPP
2009/01/14 07:23:39
(permalink)
My translation wasn't so bad. But my dictionaries are poor. I was wrong about your being a professor. I apologize. I was impressed from your discussions with Mr.Muzhd (he *is* a professor, don't say he isn't); where has he gone? Probably he's busy in his academical duties.
|
DarioG
Allmächtig.
- Total Posts : 54081
- Reward points : 0
- Joined: 2006/02/25 08:58:22
- Location: Oesterreich
- Status: offline
|