On Thu, Aug 4, 2011 at 2:46 PM, Mark Richards
<[email protected]>wrote:

> Hello Paul,
>
> On 8/4/2011 14:18, Paul Alfille wrote:
> >
> >
> > On Thu, Aug 4, 2011 at 12:41 PM, Mark Richards
> > <[email protected] <mailto:[email protected]>>
> wrote:
> >
> >
> > I'm a little confused by the "complete path". "28.CFB8C0000000" is the
> > complete path, unless you want specific bus or you are using DS2409
> > microhubs.
> >
> > If you really want to delve into the details,
> > FS_Parsedname( "28.CFB8C0000000" ) will find the device and fill in
> > the parsename structure. (You have to then clean up
> > with FS_ParsedName_destroy ).
> The current test setup has one USB interface, but there will be more:
>
>     /3A.F59800000000
>     /1F.5A1D02000000
>     /bus.0
>     /uncached
>     /settings
>     /system
>     /statistics
>     /structure
>
> I cannot find docs for the directory structure except in pieces.  Are
> these consolidated somewhere?
>
> Sorry for the poor documentation.
owfs will show a "union" view of all the 1-wire buses. Internally it keeps
track of the specific bus a device is on and will send read/write requests
to the correct bus. If you wish you can refer to the device more
specifically on the relevant bus (i.e. bus.0/10.234234234234 vs
10.234234234234) but the function is identical.

/system /settings /structure,... reveal internal program data, like the
potential properties of each device type.

/uncached functions more as a flag to the program to ignore cached results
and perform data readings directly. The list of devices in the /uncached
directory should be identical the root directory.

Makes me wonder - should I read from uncached/bus.0 which has:
>     /uncached/bus.0/interface
>     /uncached/bus.0/3A.F59800000000
>     /uncached/bus.0/1F.5A1D02000000
>
> ??
>
> ID 28.CFB8C0000000 is here: 1F.5A1D02000000/main/28.CFB8C0000000
>
> By "complete path" I mean this:
> uncached/1F.5A1D02000000/main/28.CFB8C0000000
>
> As for FS_ParsedName() when I do this:
>
>         struct parsedname pn;
>         int ret = FS_ParsedName("28.CFB8C0000000", &pn);
>
> the progam hangs at the FS_ParsedName() call
>
> Maybe in a loop?
>
> Hard to know without looking at the code.


>
>
>
> > I think an easier way would be to do a complete directory traversal
> > (i.e. GET("/") and get of every directory 1F.nnnn/main|aux ) to
> > generate a list. I think most of the data is revealed at a high level
> > (get/put or read/write/dir) than having to user low-level functions.
> Doesn't owfs have to know this when it creates the directory structure?
> Perhaps this data is already available internally?  If you can point me
> in the right direction I will attempt to expose it.  Problems then
> solved as long as I update my internal storage occasionally to account
> for dynamic changes (devices on and off the bus, ect).
>
> Why not just use owfs's facilities and let owfs figure out the device
location. Create a list be the directory traversal whenever it's needed. The
data is cached and thus pretty efficiently accessible that way.


> >     2. Does a OW_get() to a device in the uncached/ directory force, for
> >     example with temperature sensors, an immediate conversion or must I
> >     touch the temperature12 file before doing OW_get?
> >
> >
> > It's the "uncached" in the path that forces a conversion. "touch" does
> > nothing. If you look at the FUSE interface, only read, write and
> > readdir (and fstat) are actually implemented. open, close and all the
> > rest are ignored.
> So when I do a read my path must include uncached/ ??
>
If you want data more recent than up to 10 seconds old (or whatever the
volatile cache timeout is set to) then yes.

>
> >     3. Where is the conversion time stored?  Or is it logged?  It is
> >     important (to my application) to know when the result I am reading
> in,
> >     for example temperature12, was converted.
> >
> > Everything is done "on demand" so the reading is done when you call
> > read the value. If you want to avoid the caching, just use "uncached."
> >
> > The technical answer is that the timestamp for the reading is kept in
> > the cache hash table and isn't exposed to the rest of the program.
> Is the timestamp of the (as example) temperature12 is modified when it's
> updated?
> I could read that.
>
Just getting the uncached data when you actually want it isn't sufficient?


>
> /m
>
>
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Owfs-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts. 
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers

Reply via email to