- 'struct sr_input *' variables are consistently named 'in'.
- 'struct sr_input_module *' variables are consistently named 'imod'.
- 'struct sr_output *' variables are consistently named 'o'.
- 'struct sr_output_module *' variables are consistently named 'omod'.
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'
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.
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>
All of these error conditions are checked via the unit tests.
Also, add the following missing entries (analog trigger types):
- SR_TRIGGER_RISING
- SR_TRIGGER_EDGE
Use g_malloc0() for small allocations and assume they always
succeed. Simplify error handling in a few places accordingly.
Don't always sanity-check parameters for non-public (SR_PRIV)
functions, we require the developers to invoke them correctly.
This allows further error handling simplifications.
This is a feature restricted to the new analog struct.
By default all the digits available in the encoding struct are printed.
The option "digits", when set to "spec", changes this to print the
number given in the spec struct.
It fills the fields with reasonable default values that should suit
most of the drivers. Drivers are obviously free to override the fields
they want after initializing.
The automatic selections of the measured quantity and equivalent circuit
model are more part of the configuration of the meter than attributes
of the measurement result. To reflect this, model them as config keys
instead of mqflags. This allows a driver that supports remote control to
implement 'set' method for them and has the additional benefit of saveing
two flag bits.
If the number and specs of the device's channels are not static, i.e.
need to be probed, this facility is needed.
Initially this will be used for the Philips PM2800 series, where only
the model returned by *IDN? is needed. However this could also be used
to do actual discovery with vendor-specific SCPI commands.
At least the Rigol DP800 series trigger the beeper when changing
channels remotely. Which gets rather annoying when doing acquisition
on three channels as fast as you can.
Add a driver for the DER EE DE-5000 LCR meter. This meter is based on
the Cyrustek ES51919/ES51920 chipset and communicates with the host
computer via an optional connectivity kit.
The kit uses an optoisolated unidirectional link to connect to the
meter and an USB cable on the host side. Internally the connection is
using the FTDI FT232R USB UART chip i.e. from the host computer point
of view the meter is connected into an RS-232 serial port.
This driver implements just a thin shim layer for registering the
driver and uses the es51919 module for all the actual work.
Add a protocol decoder for the Cyrustek ES51919 LCR meter chip.
This chipset (together with ES51920 front-end) is supposedly used
by multiple different portable LCR meters including at least
DER EE DE-5000, Yihua V&A VA520, Mastech MS5308, Uni-T UT612,
CEM DT-9935 and various OEM rebadges of them.
The communication protocol seems to be implemented on the Cyrustek
chip itself so all the different models are expected to use the
same protocol if they implement a host connection. Unfortunately
the protocol is not available in the public documentation of the
chipset, so this implementation is based on reverse engineering it
from traffic captures.
The actual connection between the meter and the host computer may be
different from meter to meter even when based on the same chip. This
module implements a decoder for the protocol and some common helper
functions for interfacing with the meter via an RS-232 serial port.
This calculates a proper timeout value for blocking writes on the
given serial port, for the given number of bytes. Timeout is based
on a fixed 10ms OS overhead, baud rate, data bits and stop bits.
Uwe Hermann
Joel Holdsworth
Uffe Jakobsen
Bartosz Golaszewski
Mathias Katzer
Janne Huttunen
Aurelien Jacobs
Bert Vermeulen
Vincent Palatin
Tim Hatch
Martin Ling
Soeren Apel
Jens Steinhauser