Am Donnerstag, 9. Juni 2005 11:39 schrieb Paul Alfille:
> >
> > Anyway, for my project I need an automation framework (not a GUI, just a
> > library) for 1-wire devices and Linux, with some things owfs itself
> > doesn't address, e.g. timers or grouping of 1-wire chips to "devices" -
> > the goal here is to uniquely identify "devices" instead of single chips
> > and thus, allow plug'n'work. I want to develop this in Tcl (that's why
> > I'm after the binding).
> >
> > I don't know if you are interested in such a framework - it's a little
> > off the scope.
>
> You are addressing a more general problem, aggregates of 1-wire devices.
> There are a few known sensors, like the pressure sensor, that use more than
> one device to make a larger circuit.
>
> The problem is that unless there is a standard way (perhaps in device ROM)
> for the devices to autoorganize, you need outside information.
>
> This is nothing new, you need outside information to know which device is
> the rooftop temperature vs the server temp.
>
> Most approaches have been to add a layer on top of OWFS -- perhaps by
> filesystem links to better filenames, or a database.
>
> If you have a more general method or design, I'd be interested.
>
I think there are two ways to handle aggregates. The first involves a DS2409
network coupler like described in the Dallas/Maxim application note for that
chip. I find this expensive (both monetary and design) and clumsy, too, as
you can seperate the aggregates from each other, but still don't have a clue
which one is where.
The only way to get rid of this problem is the database approach you
mentioned. After the aggregates are put together, connect them to a 1-wire
bus solely and maintain a database of the chip's IDs. Put the aggregate's ID
into the database and on an adhesive label on the PCB.
Later, the personnel which does the installation can look up the aggregate's
ID from the labels and make the correct connections in the software.
There is one problem left which cannot be adressed this way: Multiple chips of
the same type in one aggregate - usually, you have no control which single
chip is mounted at which position on a PCB. The most simple solution is to
sacrifice a port pin which is connected to 5V on one chip, 0V on the other.
Another possible solution is again the DS2409 to get at least 3 identifiable
branches per device.
> >
> > > 4. TCL doesn't use SWIG, I believe.
> > > Serg Oskin is the TCL implementer, and has been very active is fixing
> > > any problems.
> >
> > Ok, I will ask him on Tcl issues. The first thing on my nails is:
> >
> >
> > BUGS
> > Simultaneous work of several connections is not supported.
>
> You can certainly aggregate several owservers. All the packages use the
> same underlying owlib that has multiple data sources built in. The only
> question is whether you can pass all their names on the "command line" --
> the invoking call. It is probably better design to "aggregate" to a local
> owserver, and then use that owserver for all the TCL calls. That allows
> more than one process to talk to the devices, and probably reduces startup
> times.
>
If I use it that way, I would have have no control about the data passed via
TCP. What happens if a local owserver cannot connect to a remote one? Does it
try again? This is really a knockout criteria, as the device should be
"self-healing" to the greatest extent possible.
Jan
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
