Hi Bert,
Am 26.10.2016 um 11:31 schrieb [email protected]:
> On 10/26/2016 11:01 AM, Matthias Heidbrink wrote:
>
>> I believe that only very common options should have static
>> keys like the SR_CONF_* ones in sigrok, but exotic or
>> manufacturer-specific ones should be passed to a driver as a single
>> SR_CONF_SPECIAL or the like key plus a string of key-value pairs
>> „key1=value1,key2=value2,key3=value3“ or better a corresponding array
>> of key-value pairs with the keys and values being strings. And
>> replies from the device the same way, of course. Due to the diversity
>> of possible functions and their possible combinations, this is quite
>> the only way to go to be able to support complex functionality of
>> some devices completely and to be sure that every possible
>> functionality can be supported, if required, without knowing it in
>> advance. If the array of pairs approach is used and an additional
>> length field is used for the values, also binary values can be
>> transferred to a driver without having to worry about escaping them.
>
> The entire point of libsigrok and its SR_CONF keys is to abstract out
> features supported by connected hardware, so clients can then support
> the generic feature across all supported hardware without running across
> device-specific issues.
I fully agree up to this point.
> 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. Often the
features available (or stable ;-)) depend on the firmware version of the
device. Series of devices with similar features are also a related issue. An
easy way to pass data to a driver or device without huge effort is even an
issue when developing a device or trying out how a new configuration key should
work. Therefore I always have been building in something like that into my
designs and it has always shown to be useful because uses showed up later that
often weren’t thought of when the API was designed originally. In many standard
APIs from very different areas I have seen have functionality to pass
proprietary commands to devices.
We have at least one feature similar to the one suggested by me in libsigrok
already: SR_CONF_SERIALCOMM takes a string containing several parameters,
including optional key/value pairs. Just image the additional effort to have
separate SR_CONF_* keys and corresponding processing in every driver for all
the parameters that can be set oder queried in a parameter to
SR_CONF_SERIALCOMM!
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.
> Of course there should be conventions concerning the keys supported,
>> also about how to query supported ones from a driver (using another
>> SR_CONF_* key?), to allow writing generic software for device
>> classes. It might make sense to orient them at SCPI commands.
>
> If you can abstract out the feature into a generic SR_CONF for
> publishing to the client, it seems to me like using that feature should
> also be doable. If not, as I said above, you don't need libsigrok.
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.
Bye, Matthias
------------------------------------------------------------------------------
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
