Hi Brian, > 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.
Did you recompile both libsigrok and PV (or sigrok-cli, resp.) after changing the enum? > > 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. That's merely for historical reasons. PV was unable to handle capturing multiple segments, which is why some drivers are tailored to the use case of acquiring only a single segment. PV now supports capture of multiple segments, so this limitation no longer applies, though some drivers don't handle this properly yet. > "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. In my opinion, this should be the default acquisition mode in the future for devices that work in segments. > 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. Yes, however emulating "normal" more by repeatedly using "single" mode does have its disadvantages, too. I would prefer that the drivers would be handling this internally to reduce overhead, make use of device-specific optimizations and increase the acquisition rate. > 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. Unfortunately, I'm not completely sure I understand. Isn't "auto" mode supposed to show the state of the inputs by means of either a regular trigger - or in absence of a valid trigger, a trigger forced by means of a timeout? If so, then for a streaming device (e.g. FX2) that has no triggers by its way of operation, "auto" mode seems to be nothing more than "normal" mode with temporarily disabled soft triggers, yes? By the way, it's not quite clear how triggers and streaming devices work together as of now. From my point of view, each trigger should end the previously begun frame (segment) and begin a new one. That way, we end up with continous data chopped up into logically separated pieces that can easily compared and examined. That's just a side note, though. > 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. Yeah, which is why I think the drivers need to be involved. For some devices, supporting auto/normal/single is trivial but for others it may not be. > 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. By the way, the capture length setting will be replaced by what you refer as a capture time setting. Having a user choose a number of samples to acquire is not very helpful - defining a time span on the other hand, may very well be. -Soeren ------------------------------------------------------------------------------ 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
