On 17/11/2015 12:45, Matthias Urlichs wrote:
> On 17.11.2015 06:39, Nigel Titley wrote:
>> iButtonlink have confirmed that the Link45/LinkUSB doesn't crawl the OW
>> bus but expects the higher level code to do this.
> The question is whether it supports the "match ROM + command+data +
> search ROM" sequence used to selectively enumerate the buses behind a
> DS2409, as required when you use one of the Smart-On commands.
Using 'b' to enter byte mode should allow you to stream this sequence,
unless it exceeds the internal buffer limits of the Link device. I'll
find out what these are.
>
> Doing this in higher-level code, i.e. by permanently turning on the main
> or aux buses, is not trivial. You'd need (external) locking, and be very
> careful about which bus segment you associate newly-discovered devices to.
Agreed
> On the other hand, all things considered I'd expect things to be faster
> with a permanent bus connection, since I'd only have to send a bus reset
> once per command (plus maybe one to select the correct bus), not per
> traversed segment. Similarly for conditional search, which is going to
> be a win for multiple DS2409s on a bus (like in a hub).
>
>
> NB: while we're looking at the DS2409 code ... OWCH:
>
> /* 2409 switch -- branch status -- note that bit value is reversed */
> static ZERO_OR_ERROR FS_r_branch(struct one_wire_query *owq)
> {
> BYTE data = 0 ;
>
> OWQ_U(owq) = (((data) & 0x01) | ((data >> 1) & 0x02)) ^ 0x03;
> return GB_to_Z_OR_E(OW_r_control(&data, PN(owq))) ;
> }
>
> Wouldn't it make slightly more sense to *first* read data and *then* set
> the return value? :-P
Heh...
> Since this code demonstrably cannot have worked since 2010 (Paul did a
> "minor cleanup" that broke it, cf. git change fc0c93a31) and nobody
> noticed, I propose to replace the currently-useless "branch" two-bit
> array with a single value (0: no bus selected, 1:main, 2:aux) that can
> be read and written to, in case one wants to (or has to) manually switch
> branches in external code.
>
> Any objections? Otherwise I'll prepare a patch.
>
No problems here.
------------------------------------------------------------------------------
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
