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 [email protected] email/xmpp ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
