Hi Paul, thanks for your detailed answer ! Am Dienstag, den 04.05.2010, 17:51 -0400 schrieb Paul Alfille: > 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.
so using bus.n sounds feasible, but is this numbering consistent through (un)plugging various adapters ?!?! i would expect following to happen: + plug in adapter 1 -> bus.0 + plug in adapter 2 -> bus.1 + remove adapter 1 -> bus.0 disappears + plug in adapter 3 -> bus.2 (! - not bus.0 !) + plug in adapter 1 -> bus.0 reappears sorry for the theoretical question, but currently i dont have that much adapters at hand to try it out ;) another question would be if the numbering is consistent when restarting owfs - although, this would not be a requirement in my case ... > > 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. ok, so all commandline switches regarding the connection can be passed as init string also ? > 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, ...) ok, i get the point ... but each usb device at least is connected to some usb bus - which could give a hint ... and in my case - as i am using dbus' udi's - i think its not possible to have twice the same entry there ... therefore i think i can distinguish them by some means ... > On the ither hand, we expose details of the "interfaces" in > (appropriately named!) bus.n/interface. thats great, i will definitely take a look at them ;) > 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). no problem, i dont want to use these ... as it's owfs we're talking about here eh ;) > > 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). ok, so i will take a look there if bus.n isnt sufficient ... > > 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. hey, thanks for the compliments ;) - i will take a closer look to the pointers you gave me ... and then come back once in a while ;) regards, marcus. ------------------------------------------------------------------------------ _______________________________________________ Owfs-developers mailing list Owfs-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/owfs-developers
