Hi list
I was recently told to to point to patches/pull-request here.
I'd like to ask you to review the following pull requests from github to bring them into trunk:
#139 (new driver for power meter),
#140 (extend driver to support more signal generators) and
#146 (new driver for power supplies).
Let me know if you really need a commit with only the skeleton. I will prepare that if it is needed.
#139 (new driver for power meter),
#140 (extend driver to support more signal generators) and
#146 (new driver for power supplies).
Let me know if you really need a commit with only the skeleton. I will prepare that if it is needed.
Same for the pull request #108, but it is outdated since it went further in the branch danselmi:bk-1856d. Should I close PR #108 and open a new one from the actual branch? Let me know if I can do anything to get these things into trunk.
If you like I can take pictures of these devices for the wiki.
I would make PR #139 more consistent between the devices if we could add something like a SR_CONF_PRESET parameter to sigrok.
It is more like a command which can only be set and will be cleared by the device automatically.
To have the device in a predefined state, just set SR_CONF_PRESET.
Yes, there is a use case when you won't use the default predefined state:
The use case is the following: to configure the analyzer manually (probably local at the analyzer) and use sigrok in a script to power-cycle the
DUT and read measured values from the analyzer. Remember, some analyzers or signal generators have thousands of options.
Maybe this is suboptimal because today SR_CONF_xxx are parameters and not commands. What do you think?
I would make PR #139 more consistent between the devices if we could add something like a SR_CONF_PRESET parameter to sigrok.
It is more like a command which can only be set and will be cleared by the device automatically.
To have the device in a predefined state, just set SR_CONF_PRESET.
Yes, there is a use case when you won't use the default predefined state:
The use case is the following: to configure the analyzer manually (probably local at the analyzer) and use sigrok in a script to power-cycle the
DUT and read measured values from the analyzer. Remember, some analyzers or signal generators have thousands of options.
Maybe this is suboptimal because today SR_CONF_xxx are parameters and not commands. What do you think?
regards danselmi
_______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
