2011/8/16 Jan Kandziora <j...@gmx.de>
> Am Dienstag, 16. August 2011, 14:11:49 schrieb Paul Alfille:
> > Did you know that --usb=ALL and --i2c=ALL:ALL will do the scanning for
> you?
> >
> Yes, but only in the back of my mind. That function isn't exactly what I
> need.
> I do this scanning once on application start. Then I have a list of host
> adapters to use.
>
> The idea is: whenever something bad happens owfs can't handle on it's own,
> I
> can drop all connections and immediately reconnect, without having to scan
> again. In the past, this was neccessary from time to time, e.g. with USB
> errors. I don't know if the situation got better, as I hadn't the time to
> look
> for onewire the past year. Second, I have to spare some serial ports that
> are
> known to be occupied, e.g. by touchscreen, printer interface etc.
>
> If there was another possiblity to find out which host adapters are in use,
> I
> would find that useful, too. Something like
> "bus.2/interface/settings/serial/device" returning "ttyS0" or major/minor
>
>
> > I think the serial hasn't actually hung, it's just a very long sequence
> > (minutes). The code certainly wasn't tuned for efficiently finding bad
> > port, but rather finding the right settings for configuration problems.
> So
> > there is a long timeout for each attempt (5 seconds) and we try many
> times
> > with both harware flow control and not.
> >
> That was my, impression, too. If we could shorten the overall process to 5s
> per port, I would be happy. Is it really neccessary to wait so long for an
> answer from the host adapter? No faster way just to probe if it is there?
>
maybe here a multi-thread to probe in parallel could help reducing a big
long loop be changed to many processes running a small probe, ex:
today:
main loop(i=first port; i< last port;i++){
probe; wait...;ok?;next
}
new idea:
number of threads<=num of ports and number of threads>=1
main loop{
create probe threads;
while all thread didn't end{wait...}
threads ended - get ports that was ok
}
thread loop(i=first port of this thread; i< last port of this thread;i++){
probe; wait...;ok?;next
}
return ok ports (maybe shared memory or another method)
with this we could allow a big for of 1 thread and 100ports (maybe
500seconds)
be changed to 100threads with 1 probe each (5seconds)
or 10threads with 10 probes each (50seconds)
must test, but the idea is better then a sequencial probe
>
>
> > We could have a "quick test" option, or even better, a little utility
> that
> > just tests whether a serial bus master is available. (just tries and
> > returns the answer, could even try the ports in parallel).
> >
> I'd like to do this with the language binding rather than with an external
> utility if I had the choice.
>
>
> Kind regards
>
> Jan
>
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> _______________________________________________
> Owfs-developers mailing list
> Owfs-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/owfs-developers
>
>
--
Roberto Spadim
Spadim Technology / SPAEmpresarial
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Owfs-developers mailing list
Owfs-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/owfs-developers
