Re: Iyonix USB: Bulk IN endpoints


Peter van der Vos wrote:
Dave Higton wrote:

I have a feeling that the bulk mode parts of the stack were written
and tested assuming a model like a mass storage device, where every
response from the device has been requested just before, and is of
an expected length. This model is not valid for USB MIDI, for
example, where all the incoming data (if indeed there are any!) are
not requested in advance, and may be of any packet size in a wide
range. I don't see either of the RISC OS stacks being able to cope
well with this sort of data on a bulk endpoint.

I need to be able to initiate a request for a non-blocking input
transfer, subsequently get the data, then loop round again. Of
course I need to be doing other things until the data arrive. If
they ever do.

On the Iyonix stack, the only way I have found to do it is with
OS_GBPB 4, having opened the pipe with short timeouts. However,
I'm not sure this is working without confusing the device.

I looked at the documentation of the Simtec stack again today, and
it appears that it's possible to initiate an input with a timeout
(in centiseconds). I haven't tried it yet, though.

I'm in the worst possible situation: I'm writing the embedded device's
code too, so I don't know which of them isn't working. :-(

Can't you create two endpoints? One with the current status of your
embedded system and the number of bytes waiting to be transmitted from
the other endpoint.

The 'data' endpoint should send bytes of a fixed lenght and pad the
unused bytes.

I'm working with a defined protocol: USB MIDI. I can't change the way
it works. I am trying to create a standards-conformant device.

Dave

.

Relevant Pages

  • Re: Persistent stall in the Cypress FX2 FIFO
    ... Are you absolutely certain that the endpoint is STALLed? ... usually means that the endpoint has received an invalid USB request. ... the master interrupt and the individual interrupt register. ... Persistent stall in the Cypress FX2 FIFO ...
    (comp.arch.embedded)
  • Re: Requesting for less than endpoint size in UsbBuildInterruptOrBulkTransferRequest
    ... If you KNOW that the device will send less data, you CAN request less that ... If the device sends more than your buffer size, ... the transfer fails, the endpoint is stalled. ... > client driver should issue a bulk request of at least endpoint size? ...
    (microsoft.public.development.device.drivers)
  • Re: KMDF1.5: Reading from USB interrupt endpoints
    ... If your request to the interrupt endpoint is larger than what the device is returning, and the device happens to be returning a multiple of its MaxPacketSize, then your request will not complete as it is waiting for more data from the device. ... code works, for example, inside VMWare (VMWare running XP32, Vista32 ... inside VMWare) but I tested this today on my AMD64 laptop with Vista32 ...
    (microsoft.public.development.device.drivers)
  • Re: Device Driver - Direct Access to Endpoint 0
    ... defined in UsbBuildVendorRequest to send requests to Endpoint 0. ... Specifies the device-defined identifier if the request is for an endpoint, ... >> I have made a USB functional driver and it is stacked on top of "usb bus ...
    (microsoft.public.development.device.drivers)
  • [PATCH 0/5] IEEE 802.15.4 stack: generic parts v3
    ... This is a third version of pull/merge request for IEEE 802.15.4 stack. ... Fixed email addresses for Sergey Lapin. ...
    (Linux-Kernel)