On Sat, Nov 09, 2013 at 01:12:42AM +0000, Martin Ling wrote:
> On Fri, Nov 08, 2013 at 09:53:14PM +0100, Mathias Grimmberger wrote:
> >
> > > I see you've been using the SCPI "*OPC" command to try to get the scope
> > > to complete each command before issuing the next. Has this gotten you
> > > anywhere?
> >
> > Can't say, I have never seen a command not having completed by the time
> > I checked the OPC bit, it's mostly just paranoia on my part. But
> > commands may execute a bit slower if more load is put on the processor,
> > maybe when FFT or protocol decoding is enabled?
>
> Ah, sorry, I had just glanced at a bit of the code with *OPC, and
> thought it was just something you'd tacked on to try to block until
> completion, hence my comments about the meaning of that command. I
> missed that actually you were reading back the SR elsewhere.
>
> > There is a difference between Agilent and Rigol regarding this. For
> > "*OPC" they agree, for "*OPC?" Agilent docs claim it will block the
> > caller until the operation completed and will always return 1, Rigol
> > says it will return either 0 or 1 and apparently won't block.
>
> The two usages are not inconsistent with each other, if a 1 from the
> Rigol reliably indicates that it has already completed the operation.
>
> I'm guessing the standard says something to the effect of "returns 1 if
> the operation is complete or 0 if the operation is not yet complete".
>
> If so both approaches are compliant, with the Agilent one "cheating" and
> just waiting before returning either, such that it can always return 1.
After reading this I implemented also a getter function for a "*OPC?"
reply that handles both cases uniformly:
https://github.com/poljar/libsigrok/commit/e264e87d2dcdc685466fdb7fdf9554f4d8d8cc65
>
> In general, the business of correctly handling command completion seems
> like something it would be good to move out into the common SCPI
> implementation that Damir Jelić has been developing (see
> https://github.com/poljar/libsigrok/blob/hameg/hardware/common/scpi.c -
> when his code is completed and merged I would like to change the Rigol
> driver to use it also).
I would go even further and propose a that we merge our effort into a
single "scpi-scope" or even "scpi" driver, if you take a closer look at
my hameg driver you will see that it actually is a rewrite of your rigol
driver in a manufacturer independent way (thats part of the reason why
I'm still not finished).
Take a look at the config_set function:
https://github.com/poljar/libsigrok/blob/710ab4af4f9a32161173245de7b44b3b787578fa/hardware/hameg-serial/protocol.c#L578
It does exactly the same thing as in the rigol driver. The only
difference would be for the SR_CONF_COUPLING case where you rename "AC
Line" to "ACL" and "CH1" to "CHAN1", for this we could add a quirks
table for different commands which would overide the default case, or you
could just put the proper names in the trigger_sources array.
The same applies to the initialization, config_get, config_list
functions.
Now the major difference between scopes seems to be in the way we need
to fetch measurement data, but even there wouldn't be more than 2-3 cases we
would need to cover.
If we merge our effort and implement the driver in a vendor independent
way we would provide an easy way for people to add support for new hardware.
Please consider this proposal.
Thanks, Damir.
------------------------------------------------------------------------------
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
