Hi, Soeren,
Thanks for looking at it.
On 1/27/2018 3:54 PM, Soeren Apel wrote:
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 tried this test again, and it worked, so perhaps not the first time.
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.
My point was: all devices currently support run single, including FX2,
because that's the only start there currently is.
It may be that all not all devices can support auto, since it requires
being able to abort waiting for a trigger and capture anyway.
"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.
Which? In scopes, "normal" is usually the default, sometimes "auto".
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.
I think there is a lot of work to be done to optimize this.
I have not studied any but the FX2 at this point, and that is because
it is the one I currently test with, though I have other options
that are also supported.
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?
FX2 is one of the easiest because it has no triggers.
Hardware trigger support complicate this issue.
And the SR_DX_XXXXX messaging does not support it now.
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 don't think its a side note at all. However, I don't understand
what you are doing, and what you see support for multiple segments is
going to accomplish. I am not disagreeing,I justdon't understand you.
I always thought of multiple captures going into separate buffers
in the high level sense. And the captures could be compared by
switching between the separate buffers, hopefully in a way that
there is no apparent time calibration shift between the various
buffers, and with very little lag.
I can't tell if this is what you mean or not. Like maybe this is
a forest and trees problem, in that I am thinking at a higher level
layer than you are.
I think the exact nature of the UI to compare captures is important,
but whatever it is could probably be implemented in several ways.
I think there is less connection between repeated triggering and
buffer management than you seem to, but this is still because
I don't understand your plan.
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.
We agree on this, but maybe only with respect to auto.
But there will need to be adjustments in the protocol.
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
