Hi Soeren, Am 26.10.2016 um 10:07 schrieb [email protected]: > From my point of view, supporting every single option might be > overkill, however. If my signal generator had a usable interface, > I'd use it to easily configure mode, frequency, amplitude, offset > and sweep. Then I'd be happy already. > > On the other hand, configuring even rarely used options via one single > sigrok-cli command line certainly has its benefits, too. That makes > me wonder whether the architecture with fixed SR_CONF_* keys (and only > those) is too rigid. We've kinda had the discussion before and it > would certainly be doable to have SR_CONF_* keys that can be registered > by drivers at runtime. That way, the SR_CONF_* table won't explode > from adding tons of really custom stuff and because libsigrok clients > can list all options, they can still support everything. > Definitely doable, just needs a bit of work to make it happen as the > current structures are static (e.g. arrays). > > Any more opinions? Uwe?
I would also like support for signal generators because I have some devices with limited signal generation functionality that I would like to support. 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. 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. Just my 2 ct. 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
