On Sat, Nov 09, 2013 at 03:46:45PM +0100, Damir Jelić wrote:
>
> > 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.
>
> Of course it would not work with new devices out of the box, but the
> amount of work to add a new device (provided that it is an SCPI device)
> would be vastly decreased. Just fill out a struct and you most probably
> would be good to go (note the acquisition handling is still missing):
>
> https://github.com/poljar/libsigrok/blob/710ab4af4f9a32161173245de7b44b3b787578fa/hardware/hameg-serial/protocol.c#L178
Two points:
Firstly, the work isn't decreased any further by having everything in an
"scpi-scope" driver rather than just having the same code in some common
internal module.
Secondly, think it's hard to say at the moment whether the single driver
approach is actually helpful in the long run. Right now the Hameg scopes
you're working on are very similar to the Rigols and those are the only
two we're dealing with, so everything seems simple.
But I'm concerned that down the line, somebody comes along with an SCPI
device that is substantially different in some way we haven't thought
of. It's still an SCPI device so they extend the abstraction to cover
it, which complicates it a little more, and then something else comes
along and does the same thing, and something else again, and suddenly
rather than "hey all the code I need is written already!" the next new
developer is thinking "how the hell am I supposed to adapt this driver
to work for my device? And without breaking all these other devices I
don't have acess to to test against?"
Yes, right now this is a straw man argument, but my point is a general
one: over-generalising things before all potential use cases are known
often leads to architectures that cause problems later.
> Well the point is that there is almost nothing device-specific between
> our devices (I also checked the Agilent programming guide) and the
> differences between features could be easily defined inside of a
> structure. If there happen to be some differences a small quirk table
> would be enough to fix them.
Even if everything for a new Acme 123 device can be defined inside of a
structure such and no new code needs to be written, I still think it
makes sense to start a new acme-123.c driver to put that struct in.
We're not talking about trivial definitions here. The definitions for
the Hameg driver add up to about 200 lines.
> > 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.
>
> I don't think that we should put anything that is not mandated by the
> SCPI spec into scpi.c (so no device specific commands should go into
> there).
That makes sense, but scpi.c isn't the only place this stuff can go. I
would put the stuff we're discussing at the moment in somewhere like
hardware/common/scpi_scope.c. It can build on top of the scpi.c
functions to implement the higher level functionality, and be called
into by individual scope drivers which include the device-specific
details (be they data, code, or both).
Martin
------------------------------------------------------------------------------
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
