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 <kirk...@pdx.edu> 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 <danieljayfergu...@gmail.com>:
>> 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
>> 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
>> 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
>> 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.
>> HL read request is left in the list to be submitted again.
>> when the client reads, data is dequeued from the circular queue and
>> to the user without blocking.
>> Where to find stuff:
>> repo dir:
>> IsocHostInterface/isoc_interface.h <---suggested reading
>> IsocHostInterface/isoc_interface.c <---suggested reading
> psas-avionics mailing list
psas-avionics mailing list