On Tue, May 4, 2010 at 3:25 PM, Marcus Priesch <mar...@priesch.priv.at> wrote: > but in the case of owfs - with multiple usb adapters - i would have: > n interfaces - n sensors > and i can not distinguish which sensors are connected to which adapter. > ... or am i wrong with this - havent tried it tough ... ;)
You can look at the bus.n directories which correspond to a particular "interface" in your parlance. In fact you can drill down several layers of bus.n if your topology warrants. > currently it is not possible to force the use of a proper usb adaptor to > talk to - only "-u" (the first), "-u2" (the "second") and "-uall" (all > found adaptors) are possible ... and in fact i am wondering if i can > also specify this in owcapi ... havent tried this either ;) Yes, owcapi should take standard arguments as the init string. I presume the python implementation passes the init string along. The problem with USB (at least as presented in libusb) is that the usb devices are enumerated in unpredictable order. So it's harder to know which DS9490 you'll find in what order. You can use the 1wire ID that many of the DS9490's have (family code 81) to identify them, and that's what we try to do internally, but it does get complex with many corner cases (some home made 9490s don't have an ID, early 9490's had family code 01, a bus short will mask all devices, ...) On the ither hand, we expose details of the "interfaces" in (appropriately named!) bus.n/interface. I should warn you that if you use the kernel "wire" (formerly w1 and wire1) module, there is no way to distinguish interfaces and devices. And the interface enumeration is even more fluid and unpredictable (i2c masters and GPIO masters will be mixed in with the USB masters). > so, the question is, will it be possible (technically) to modify owfs to > specify the usb device to use in some manner - i am thinking of an > additional parameter to specify all needed values for libusb > initialisation ... I haven't looked too closely at libusb1, the libusb 1.x implementation. It may have this ability. If so, I'm quite open to updating the version of libusb we use (currently 0.12). > paul, if you find this a good idea - and propably could give me some > hints on how to start, i am definitely willing to get my hands dirty on > this ... ;) - and it would definitely improve my sensorlib's design :) I'd love to work with you. My first thought is to explore the bus.n facility and see if some simple extentions will satisfy your requirements. Paul Alfille ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
