from the client perspective - which is the High level request:
'read' is simply to gather data from a FIFO that may or may not have new
data in it.

from libusb perspective - which is the low level request - and the level
which the API attempts to abstract away:
'read' is an asynchronous request. when the request is completed..the
received data is put into the FIFO.

On Sat, Sep 18, 2010 at 10:25 PM, I <> wrote:

> A couple of questions from someone familiar with real-time, distributed
> communication; but not with usb isoc...
> When you say 'read', are you describing the process that 1) requests
> information from a remote source, 2) waits for the reply, and then 3)
> returns that information to an application calling the read?
> Alternatively, does a 'read' simply gather data from a FIFO that may or may
> not have new data in it?
> Quoting Daniel Ferguson <>:
>  Hi,
>> I'm working on a layer that sits directly on top of libusb for isochronous
>> usb transfers...
>> the more people who see what i'm doing, earlier, the better.
>> the gist is thus:
>> Both read and write have three parts.
>> 1) the high level(HL) request
>> 2) the low level(LL) request
>> 3) the result
>> The high level request is what is visible to the client of the API. it is
>> very similar in nature to a normal read and write on a normal file in
>> linux.
>> The low level request is used internally to the API. the API converts the
>> high level request into a low level request and submits the low level
>> request to libusb.
>> The result is just a result. In the case of a read, it is the data. in the
>> case of a write, it is confirmation.
>> The Write Process:
>> A HL write requestgoes into a list.
>> A dedicated thread gets the HL write request from the list, converts it to
>> a
>> LL write request and then submits the LL write request to libusb. When the
>> LL write request completes, the HL write request is removed from the list.
>> The write process is designed to be used by commands that are one-shot.
>> The Read Process:
>> before the start of communication, a batch of HL read requests are
>> inserted
>> into a list.
>> A dedicated thread iterates through the list of HL read requests, converts
>> them to LL read requests and submits them to libusb. When the LL read
>> request completes, the received data is enqueued into a circular queue.
>> the
>> HL read request is left in the list to be submitted again.
>> when the client reads, data is dequeued from the circular queue and
>> returned
>> to the user without blocking.
>> discuss....
>> Where to find stuff:
>> branch:
>>   USBEndToEndTest
>> repo dir:
>>   freertos-5.1.2-lpc23xx/USBAllTest1/host/
>> Players:
>>   list/list.h
>>   list/list.c
>>   queue/cqueue.h
>>   queue/cqueue.c
>>   IsocHostInterface/isoc_interface.h         <---suggested reading
>>   IsocHostInterface/isoc_interface.c         <---suggested reading
>>   IsocHostInterface/isoc_interface_test.c
>> Cheers,
>> ~Daniel
> _______________________________________________
> psas-avionics mailing list
psas-avionics mailing list

Reply via email to