On 10/26/2016 02:25 PM, Matthias Heidbrink wrote: >> Supporting special, unabstracted features might make sense for >> hardware that's hard to talk to except through the libsigrok >> driver, for example in case of an obscure binary protocol. But SCPI >> is easy to get to. If you're going to write a client for some >> device's specific features, why involve libsigrok at all? It would >> just get in the way. > > It is no problem to write a client software, e.g. a GUI for a > multimeter, logic analyzer or oscilloscope, in a way that you have > generic functionality that will work with every device of the > corresponding class plus a specific, additional functionality, e.g. > in separate GUI elements/menu items/plugins, that are present or > visible only when a matching device type is present. In my view this > possibility makes sense especially for open-source software to avoid > duplicate work. In object-oriented programming design patterns exist > to support such functionality, but of course a way through the > interface to the driver/device is also required. In my view it would > be absolutely insane having to write a software for my device from > scratch or forking sigrok* projects in a way where’s no way back just > because my device has got a proprietary feature that I would like to > have supported. And you always get to this point sooner or later when > wanting to take full control over a complex device.
You make a good point, I admit I've come across this myself. > If there were a feature to pass raw SCPI commands from an application > to a device (haven’t seen anything like that in sigrok yet, but I’m > not up to date with the current status of the project), this would be > almost the same, although less generic. Actually this could be one of > the first applications for my suggestion. SCPI is a good match because it's at least a two-way protocol, and tends to be used in complex devices. > The problem with this approach is that at the time you design > something like a SR_CONF key with a specific semantics, usually you > don’t know all devices on the market, and even future ones, and their > functionality in the corresponding area. I often learned the way how > a certain feature of a device worked only when implementing it, also > often due to unintelligible or wrong docs or undocumented behaviour. Yup, also true. Anyway I think you make a good case for this. Anyone agree/disagree or want to implement? -- Bert Vermeulen [email protected] ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
