On 10/26/2016 11:01 AM, Matthias Heidbrink wrote: > I did not take part in sigrok development and such discussions > recently, but did some designs of other APIs and protocol stacks over > the years. 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. 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. > 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. -- 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
