On Sat, 2009-05-23 at 03:57 -0700, David Brownell wrote: > > >> I am also thinking that the USB timeout value may be extended a bit > > >> longer. > > >> Right now it is 1000ms. Should be ok. But may not be ok for people > > >> using VM or similar. > > > > > > The problem with this is that it slows down the failure process when > > > something is actually broken. I think more intelligence is needed, not > > > just a different default setting. > > Considering that USB bulk transfers are "best effort" and might easily > be delayed by concurrent activity to a USB disk or webcam ... a single > second seems absurdly short. Even if the device were guaranteed to be > able to respond that quickly.
Right, but that does not mean we should simply throw the program into a blocking call with a longer timeout. I would rather see the device make a try using a _shorter_ timeout and allow for other processing to occur in between retries. That "other" work might be something as simple as a progress bar, but we could take this design a step further. It is not hard to imagine introducing the ability for the interface to attempt endless retries, requiring the user to cancel the request interactively (or kill the program outright). Or does this seem silly? Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
