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>: > > 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@lists.psas.pdx.edu > http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics >
_______________________________________________ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
