Am Samstag, 18. November 2006 22:52 schrieb Paul Alfille:
> That's not good.
>
If 160ms/scan is the worst time you measured, it means there's hope I don't
need to change parts of the machine design. Scanning locks connected to an
USB adaptor is quite faster (at least on my development PC), but the machine
should use the DS2482-800 instead.
I will setup a stable measurement environment on the actual platform around
next wednesday.
> If we can't resolve it this way, we may have to add a special "file" that
> checks for ANY device on the bus rapidly.
>
Hm. I don't understand where the difference would be. Could you explain?
My idea was, the problem lies somewhere in the timing of onewire or i2c, or in
the timing requirements of the host OS. To achieve a rapid scan of a
(sub)bus, one has to issue the "triplet" command rapidly. This could exhaust
the process' timeslice and such, the owserver etc. is getting "niced". Maybe
a static priority for owserver helps? I haven't checked so far.
Kind regards
Jan
--
Alles Schwere kommt von oben...
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Owfs-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/owfs-developers
