On Fri, Nov 01, 2013 at 08:36:53PM +0100, Mathias Grimmberger wrote: > > What I implemented now is to recognize whether the scope is already > stopped and decide from that. We don't have the capability to completely > configure the thing anyway, so may as well take some hints from how the > user has set up the device. Complete configurability should wait for the > LibreVISA version, there are just so many options I don't think it's > worth implementing everything twice.
The change to using librevisa isn't going to affect the driver code much, it's just the transport. Basically rigol_ds_send will switch to using librevisa to send its messages and the serial_read calls will be replaced with some other librevisa call. But the content of the protocol will be the same, so things implemented now will not be wasted. > AFAIK the software uses the NIVISA runtime. NIVISA should come with a > nifty tool called "nispy.exe" or similar - it does what the name > suggests. It I think that will show the higher level queries made to the driver, I'd be more interested in what it's actually sending on the wire to the device. But I may give it a try at some point. > > It would be nice if sigrok could also support this sort of "live" > > operation, where the only thing we know about the timing of the data is > > that it's recent and should be displayed immediately. But I think this > > would need to be explicitly requested somehow, because it's not what any > > of the current tools expect. > > Would what I explained above, i.e. using the state of the scope when > recognizing the device (or maybe when starting the capture, makes a > difference for pulseview?) be OK? I think the use cases are as follows: 1. Batch / offline tools e.g. sigrok-cli, custom python scripts, etc. These are currently really expecting to be the sole user of a device that is initially in some idle state. They set up the device as desired for a capture, do the capture, and expect meaningful data. For these we want to first stop the scope, and then run single-trigger captures for as many frames as desired, to be sure we're always getting a complete coherent frame. This should be the default behaviour and should not depend on whether the scope is initially running or stopped. These tools should be usable unattended with consistent results. 2. GUI tools that don't provide a continuously updating display, e.g. current versions of PulseView. Basically these should be handled as for 1. 3. GUI tools that provide a continuously updating display (none yet existing but I would like to write one!) These should explicitly request that they are willing to accept "live" data which is for immediate display but does not have a well-defined relationship to any individual frame or trigger event. This will require some new API in libsigrok, I think. For this case, the current state of the device could be used to decide whether the tool starts up running or stopped by default. But I think that's the only time when we should care about that. Martin ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
