Most of the points you made I had thought about, but didn't have the actual facts.
There is something I need to understand better. I already know that if you change the order of the states in the capture_state enum, it breaks something, and I suspect it is in the link to libsigrok, since everything else seems to properly work off the enumeration names. I don't yet know what the issue is.
I think we should have three separate buttons: - Run with a drop-down to select "Auto" and "Normal" modes - Run single (only shown if the hardware supports it, e.g. hidden for FX2 devices) - Stop
We have a difference in interpretation here. In my view, all of the devices currently work in what corresponds to "single-sweep" mode on an oscilloscope. "Single" mode in my comments. "Normal" mode is when the trigger automatically rearms (usually with some rearm delay, sometimes tweakable, sometimes not) and captures (sweeps) again if another trigger event goes by. Virtually all oscilloscopes support this internally. Many LA's do also. All devices should be able to do this, just by having the state machine emulate it by calling start-capture again (after a suitable delay). So, all support single and normal. This is my current proof-of-concept branch works. Auto is the problem. I am thinking that a little tweaking of the pv protocol might support auto on most of the FX2-like devices simply by changing some aspects of soft-trigger.c If the device were simply left streaming data constantly, then the stream forwarding could be switched on and off for any reason soft-trigger saw fit to do it. I understand this won't work for many devices that have the two state machine internally, which probably includes most of the fast ones that also usually use internal buffers. But, even in this case an open-source one could be (re-)designed that would be able to do it. Even if the auto mode were incorporated into the FPGA, for example. And sigrok could adapt to honoring most any built in auto mode that any instrument supports internally, by watching for however a new capture is announced. I think you are right that the auto capability would have to use some sort of device specific property description though. However, that is also already true of the capture-rate and capture-time selectors in at least some cases. Cenkron ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
