Fix "undefined reference to `sigrok::EnumValue<sigrok::LogLevel,
sr_loglevel>::_values'", which happens at least when using clang(++),
e.g. on Linux, Mac OS X, or FreeBSD.
This fixes bug #534.
Thanks to Uffe Jakobsen and Martin Ling for reporting and investigating!
Currently (as of date 20150122) an ioctl problem within the
FreeBSD kernel is preventing libusb_get_port_numbers() from working.
Hence calls to libusb_get_port_numbers() will always return 0.
This makes it impossible to establish a physical path the the usb device.
This problem has existed "forever" -
meaning that libusb_get_port_numbers() has never worked.
A fix is committed to FreeBSD "current" head -
and will later be merged (MFC'ed) to maintenance branches.
See: https://svnweb.freebsd.org/base?view=revision&revision=277417
Additionally FreeBSD requires that devices prior to calling
libusb_get_port_numbers() have been opened with libusb_open().
The patch is "forwards-compatible".
Currently it acts specificly to libusb_get_port_numbers()
currently returning 0 on FreeBSD.
In these situations it constructs an artificial path to the device.
When FreeBSD kernels appears with proper working ioctl
supporting libusb_get_port_numbers() the code will construct
proper physical paths for newer kernels - while still generating
artificial physical paths for older defective kernels.
Add new config options to libsigrok - 'averaging', which allows to
enable averaging of samples and 'avg_samples' for setting the number
of samples to be averaged over in each cycle.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This fixes a Doxygen warning:
src/input/input.c:209: warning: The following parameters of sr_input_new(const struct sr_input_module *imod, GHashTable *options) are not documented:
parameter 'imod'
As per upstream docs "#include <glibmm.h>" is the correct usage,
the "glibmm-2.4" directory is handled correctly via pkg-config:
$ pkg-config --cflags glibmm-2.4
-I/usr/include/glibmm-2.4 [...]
libsigrokcxx.pc has a "Requires" field listing "libsigrok" which
will cause libsigrok's "Requires.private" entries to be used/inherited
when 'pkg-config --libs --static libsigrokcxx' is used.
On a Hameg HMO1024 you get incomplete data because the USB transfer takes
longer than the scpi->read_timeout_ms of 1 second that is defined in
scpi_dev_inst_new(). Therefore reset the timeout in sr_scpi_get_string()
whenever the device sends a partial response.
Since every individual measurement is represented by a single frame
and a "sample" isn't all that meaningful concept in this context,
it makes more sense to define possible limit in number of frames.
Make the es51919 driver to support setting a frame limit instead of
a sample limit.
In most, but not all, modes the ES51919 reports two separate
analog values for each measurement sample. These values are
mapped to two separate channels and sent in two separate
packets.
A client program needs a way to determine which results are
parts of the same measurement and also know when a complete
measurement is received so it can process the sample. Use
the frame begin and end packets to separate groups that each
represent a single complete measurement.
This removes an unnecessary build dependency on JDK and fixes
build troubles on systems where javac is present but JDK is not
installed and Java bindings are disabled by ./configure --disable-java.
When libusb cannot access a device, libusb_get_port_numbers() will return
an error. Check the return code rather than doing invalid pointer
operations (out-of-bound read).
Avoid segfaults at sigrok-cli startup on my setup where some USB devices are
not accessible and also make Valgrind happier.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>