Re: [sigrok-devel] libsigrok device drivers and client API

[Bert V. <be...@bi...>]

On 10/26/2014 11:31 AM, Janne Huttunen wrote:

>> Ideally, the channel name should match what is printed on the
>> case of the device. This applies well to multi channel devices,
>> such as a power supply which will have labels on the front panel
>> such as CH1 and CH2.
> 
> Ok, makes sense. How about channel indexes? What should
> they represent?

They're just the order in which they were allocated within the sdi, really
it's the same order in which they appear in the sdi->channels GSList, but
more easily accessible. These index numbers should never duplicate, obviously.

>>> There probably should be some sensible method of determining
>>> which drivers support certain device type.
>>
>> There is already one.
>> Grab the DEVICE_OPTIONS with sr_config_list() and check that
>> the list contains SR_CONF_LCRMETER.
> 
> Yes, but that currently doesn't always work if I don't have
> the device yet (sdi == NULL). At least these drivers return
> an error if DEVICE_OPTIONS are tried to be listed without
> a device:
> 
> atten-pps3203
> demo
> hameg-hmo
> manson-hcs-3xxx
> motech-lps-301
> scpi-pps
> yokogawa-dlm
> 
> Of course if you think that is a bug, they can be fixed. Some
> of those may in reality not even care about the device at all,
> but just happen to check that one is given and return an error
> if there isn't one.

Yeah, this is arguably a bug. These drivers basically present different
options based on the type of device found, and on whether a channel group
was selected. But they should also be returning what they can even without a
device, such as SR_CONF_LCRMETER.

> I somehow have a feeling (but I might be totally wrong here)
> that the whole config key thing is currently a bit too much
> a wild wild west i.e. it is very flexible and can be used for
> just about anything, but at the same time it is not all that
> well documented what keys are supposed to be returned by
> various device types under various conditions. And at the same
> time the keys are not some "auxiliary" information, but contain
> essential information for the client program. Having consistent
> abstractions also in the keys and their expected values is
> a very good thing indeed.

Well, perhaps. What isn't in there is some sort of "class" for these config
keys, and I assuming that's what you're aiming at. I'm not entirely sure
it's needed though. The device type keys (SR_CONF_LCRMETER,
SR_CONF_OSCILLOSCOPE, ...) have to be known by the client anyway, at least
the ones it cares about, so a class on them wouldn't help much.

The _CONN and _SERIALCOMM keys are "special", which is not ideal, but again
clients know about these anyway as they take specifically formatted values.

The rest are just things you can get/set/list according to the published
capabilities and depending on channel group -- they'd end up in the same class.


-- 
Bert Vermeulen        be...@bi...          email/xmpp