Thank you for asking these questions. The motivation was to further simplify the interface, whilst maintaining sensor generic-ness. And then the plan, barring course changing discussions, would be to build a sensor specific layer on top of that.
My main reason for threads is so read requests can be continually submitted, and the process to be transparent. In using libusb with isochronous transfers, in conjunction with the scenario written below, I have to submit many read requests in order to keep up with the data coming from the device. So, this code abstracts that away. I can't justify why there is a writer thread.. The scenario: Testing has been with device side code that continually increments a value and sends it. the incremented value is 4 bytes, and is within a 128 byte isoc packet(up to 1023 bytes). The idea that there are "isoc packets" and "sensor packets", where the former can be much larger than the latter creates an idiom where each isoc packet is a batch in an of itself. By leveraging that, my justification for reader threads could be moot depending on sensor packet sizes and sampling rates. Finally: Let's say, which is more or less true, that we have no isoc infrastructure, other than a few light hearted examples in the repo. I'd like to hear some ideas on how to go about building the infrastructure to accomplish end to end communication. I'd like to continue moving this effort forward in a way that fosters round-table discussions and motivated by general consensus. I expect replies...or else... i'll continue in my wayward direction. P.S.: Realistically, the effort I have put in may have yielded no result other than an increased understanding by me. I consider that a big win. Cheers, Daniel On Tue, Sep 21, 2010 at 1:53 PM, ja...@minilop.net <ja...@minilop.net>wrote: > Hello! It looks like you're building an interface for high-performance > isoc transfers, so that's cool. I don't understand what motivated it > though, so I have a couple of questions. > > What led you to choose creating a thread for reads and writes? On > reviewing the libusb 1.0 documentation it looks like the asynchronous > API does everything I think you want without worrying about > synchronizing across threads; so what did I miss? > > What difficulty did you encounter in using libusb that you're trying > to solve with a higher-level abstraction? Is there some way libusb > could be improved that would be easier than writing and maintaining a > separate library? > > Thanks, > Jamey >
_______________________________________________ psas-avionics mailing list psas-avionics@lists.psas.pdx.edu http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
