Since the DER EE DE-5000 driver is currently the only user of
the es51919 module and it depends on the libserialport, compile
the module only if the DER EE DE-5000 driver is enabled. This
allows libsigrok to be built without libserialport again.
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.
libgpib is the userspace component to linux-gpib's kernel modules that
implement low-level interface drivers.
When libsigrok gets userspace GPIB interface drivers, that backend will
be the "official" scpi_gpib.
This silences stuff like this (among others), depending on the
Doxygen version used:
Warning: Tag `XML_SCHEMA' at line 1814 of file `Doxyfile' has become
obsolete. To avoid this warning please remove this line from your
configuration file or upgrade it using "doxygen -u"
The Brymen BM25x series supports the BC-20X that is an opto-isolated
serial cable. The link seems to be unidirectional i.e. when activated
the DMM periodically sends updates to the host while the host cannot
control the DMM in any way.
The protocol is documented in "6000-count-digital-multimeters-r1.pdf"
that is available from the manufacturer. Every 15 byte packet consists
of a bitmap where the bits correspond to segments or symbols on the
LCD display i.e. the DMM essentially sends the contents of its screen
to the host in every update. This driver then decodes the measured
quantity, unit and its value from the bitmap.
This is needed so that the C++ bindings, the header for which
references "libsigrok/libsigrok.h", can have a valid include
directory passed to build them before the headers are installed.
The new triggers consist of a set of structs and an API to manipulate
them. Both logic and analog triggers are supported, in an unlimited
number of stages.
A single struct sr_trigger containing its stages and triggers is then
added to the session.
In case of a driver where the hardware supports triggering, the struct
is then converted and used to arm the hardware trigger. Drivers without
hardware trigger support, such as fx2lafw or multimeter drivers, use it
as the basis for a software-based trigger implementation instead.
This driver is neither working nor has it been in a compiling state for
a long time, so unhook it from the build until it is fixed and works.
The files (api.c and protocol.[ch]) are still in git, but won't end up in
released tarballs and they don't get built (neither git nor tarballs).
This also allows us to drop the otherwise unneeded dependency on libudev.
When the MSO-19 driver comes back, it should be in a form that doesn't
require the inherently Linux-only libudev anyway. See also:
http://sigrok.org/bugzilla/show_bug.cgi?id=65
This driver has been unmaintained for years, and was never good code
to begin with. It's also questionable whether it was ever useful,
particularly with the demo driver now supporting various analog
signalling.
Instead of >= 44 Makefile.am's we now only have one top-level
Makefile.am, and use the 'subdir-objects' automake option to
handle the build via non-recursive (auto)make.
This has the advantage of fewer (boilerplate or other) files and less
clutter in general, as well as performance advantages since the new
setup can build many files in parallel (with 'make -j'), not only 2 or 3
files within the same (e.g. hardware/xxxx/* subdirectory) and also since
we no longer need to build intermediate libtool helper libs per subdirectory.
A quick, non-scientific test build on a quad-core laptop with 'make -j 4'
yields a build time reduction from 35s to 19s.
All autotools features that worked before are still intact without any
regressions, including the Make targets 'install', 'uninstall', 'check',
'dist', 'clean', 'distclean' and so on, as well as all the usual portability
handling (build works on any OS, with any Make implementation such as
GNU Make or BSD Make, with any shell such as sh/ksh/zsh/bash/dash, etc. etc.)
and features such as out-of-tree build support, cross-compile support,
testsuite support (also with colored output), "silent make rules", etc. etc.
This adds a suite of unit tests for libsigrok. It uses the 'Check'
tool/library (apt-get install check) to run the tests.
The configure tool tries to find libcheck. If it succeeds, a
"make check" will run all tests. Otherwise, none of the tests will
be built and "make check" will not run any tests.
This also means that users who don't have 'check' installed will still
be able to build and install libsigrok just fine.
All frontends will have to include <libsigrok/libsigrok.h> from now on.
This header includes proto.h and version.h, both installed from the
distribution into $INCLUDE/libsigrok/ as well.
The only dynamically changed header is now version.h, which has both
libsigrok and libtool compile-time versions in it.
We no longer expect firmware files to be in the
$prefix/share/libsigrok/firmware directory, as that would require an
additional (distro) package 'sigrok-firmware' or the like to install
files into another package's (libsigrok) path, which can be problematic.
The current 'sigrok-firmware' repo's "make install" will already install
all files into $prefix/share/sigrok-firmware.
If the (generated) ChangeLog file is marked for DISTCLEANFILES, it'll be
removed whenever "make distclean" is called (and is then gone forever if
you use the tarballs, for example).
The udev rules file is libsigrok-specific, the gnuplot files too.
The nsis files stay in the top-level contrib/ for now, they're not
really part of any of the (sub-)projects, but rather are used to create
a single Windows .exe installer for all of them.
In the lib, we should only #include "sigrok.h" or "sigrok-internal.h",
but not the (possibly installed and thus different/older versions) via
<sigrok.h> or <sigrok-internal.h>.
Frontends should of course use <sigrok.h> and <sigrok-internal.h>.
We should use these (internal) functions in libsigrok exclusively from
now on, i.e. no more use of glib's g_debug() etc.
These functions are only for libsigrok, the frontends use whatever
logging mechanism is suitable there.
Uwe Hermann
Janne Huttunen
Martin Ling
Bert Vermeulen
Marcus Comstedt
Soeren Apel
magnuskarlsson
Kumar Abhishek
Matthias Heidbrink
Alexandru Gagniuc