Hi Damir,
I think that sharing as much code as possible between SCPI style devices
is a good idea, but I don't think a single "scpi" or even "scpi-scope"
driver is going to be the best approach to that. If the protocol allowed
enumerating all the supported settings and allowable values it might
make sense, but in practice you need to know all the supported commands,
and possible values for each device, to be able to support it.
So the "scpi-scope" driver would never actually be a generic driver that
could work out of the box for a new device - it would need to have new
devices continuously added to it.
I think it makes more sense to to retain separate drivers for different
families of device, so that there's a clear place for all this
device-specific stuff to live for each one.
We can still share almost all the protocol code, e.g. much of
config_{get,set,list} could be implemented in the common SCPI library,
with the driver just providing some data structure describing the
supported options.
What do you think?
Martin
On Sat, Nov 09, 2013 at 01:26:12PM +0100, Damir Jelić wrote:
>
> 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
