These two drivers are currently unfinished and don't work, so disable
and "unhook" them for now in preparation of the next libsigrok release.
They're still in the git repository, but not hooked up to the build
system, so that they won't get detected or built, and also don't end up
in the release tarball.
Since link-mso19 is the only driver that currently requires libudev,
drop any reference to that, too.
It should be relatively easy to apply this patch in reverse after the
release to bring back both drivers.
These two drivers are currently unfinished and don't work, so disable
and "unhook" them for now in preparation of the next libsigrok release.
They're still in the git repository, but not hooked up to the build
system, so that they won't get detected or built, and also don't end up
in the release tarball.
Since link-mso19 is the only driver that currently requires libudev,
drop any reference to that, too.
It should be relatively easy to apply this patch in reverse after the
release to bring back both drivers.
sr_config_get() provides a GVariant owned by the caller, so it must be
released with g_variant_unref() when done.
sr_config_set() takes a GVariant from the caller which may be floating;
it will be properly sunk and release after use by this function. Thus
the output of g_variant_new_*() may be used as an argument.
sr_config_list() also provides a GVariant owned by the caller, to be
unreferenced when done.
sr_config_make() can take a floating reference.
- Explicitly list .config_get in all drivers for consistency, and set it
to NULL if unused (whether or not a driver implements it is optional).
- List all 'struct sr_dev_driver' entries in the same order in all drivers.
- Move the check whether .config_set/.config_list exist (i.e., are non-NULL)
into sanity_check_all_drivers().
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
Also, do some minor whitespace and consistency improvements.
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
Also, change one SR_ERR to the more correct SR_ERR_MALLOC, and assign
sr_ctx in the rigol-ds1xx2's hw_init() function, like all the other
drivers do.
This takes an sr_config key and returns a list of possible values for
that key to be submitted with config_set(). The format of the list and
its contents is dependent on the key.
This will replace the SR_DI_* keys that returned such a list before,
such as SR_DI_SAMPLERATES.
The alsa driver was out of date wrt APIs and libsigrok conventions in
general, and wasn't compiling.
This fixes the compile and updates it to _basically_ work with the current
state of analog support in libsigrok.
This is not finished/full support for ALSA analog sampling yet, though,
various TODOs remain that will be addressed later.
This works with the UNI-T UT-D02 (RS232) cable. For the USB/HID
based cable (UNI-T UT-D04), the uni-t-dmm driver must be used.
Note: This is untested, but should work just fine for all settings, with
the possible exception of temperature (testers needed!)
Use the infrastructure of serial-dmm to handle the RadioShack 22-812,
and completely remove radioshack-dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Prepare the tekpower-dmm driver to be able to support various simple
serial port based DMMs.
Also, make a 'tekpower-tp4000zc' "first-class" driver which is currently
the only user of this generic driver.
The 'uni-t-dmm' driver/directory will not appear as a "driver" to
frontends anymore, it's just an internal thing.
The frontends will see a uni-t-ut61d and voltcraft-vc820 driver now,
with the correct names and parsers etc. attached to them.
This is not fully finished yet, but it's a start (and works mostly):
$ sigrok-cli -D
The following devices were found:
UNI-T UT61D with 1 probe: P1
Voltcraft VC-820 with 1 probe: P1
$ sigrok-cli --driver voltcraft-vc820 -D
The following devices were found:
Voltcraft VC-820 with 1 probe: P1
$ sigrok-cli --driver uni-t-ut61d -D
The following devices were found:
UNI-T UT61D with 1 probe: P1
# Now attaching a UNI-T UT61D device via USB.
$ sigrok-cli --driver uni-t-ut61d --samples 3 -O analog
P1: -0.017800 V DC
P1: -0.017600 V DC
P1: -0.017700 V DC
# Now attaching a Voltcraft VC-820 device via USB instead.
$ sigrok-cli --driver voltcraft-vc820 --samples 3 -O analog
P1: -0.319200 V DC
P1: -0.319300 V DC
P1: -0.319300 V DC
To find a driver or device option by name, the sr_drvopt_name_get() and
sr_devopt_name_get() calls are now available. This was the only reason the
driver and device struct sr_hwcap_option arrays were published.
There is no point in libsigrok copying probe lists around. The driver now
builds a list of probes according to the model device it found, and will
make that available to a frontend. The frontend thus has a reference of
what the driver has, including default names, and doesn't need libsigrok
to provide an unnecessary level of abstraction.
The sr_probe_new() library-private function is a helper for drivers.
init() now only does whatever administrative stuff it needs (typically not
much), and returns an error code.
scan() can be called multiple times during the life of an application, and
returns a GSList of struct sr_dev_inst * of devices found during that scan.
The instances are a copy of the ones stored in the driver's own instance
list, to be freed by the caller with g_slist_free() only.
The scan() call can be passed a GSList of struct sr_hwopt *, to direct the
scanning.
SR_HWOPT_* entries are driver options, not device instance parameters, so
they will never be mixed together.
Also, driver options are always passed in a GSList, where the data field
is a struct sr_hwopt.
It was actually used in one way: the session file loaded abused it for
passing in the filename -- something it definitely wasn't intended for.
This now uses the proper way to pass arguments to a driver: the new
SR_HWCAP_SESSIONFILE.
The OLS driver could also use it as an indication of the serial port to
use instead of actively probing all serial ports on the system, but there
wasn't any frontend code that passed in such a parameter, making it
entirely useless. That will soon be handled differently with the new
scan() API call, regardless.
Florian Steinhardt
Bert Vermeulen
Marc Schink
Uwe Hermann
Alexandru Gagniuc
Joel Holdsworth
Martin Ling
Peter Stuge