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.
Two error checks had a missing "ret = ", which lead to an incorrect
value being passed to libusb_error_name().
Also, lower the level for those messages from sr_err() to sr_dbg()
since they're not fatal.
CC libsigrok_hw_common_la-usb.lo
usb.c:241:18: warning: no previous prototype for 'usb_thread'
[-Wmissing-prototypes]
SR_PRIV gpointer usb_thread(gpointer data)
^
usb.c:256:13: warning: no previous prototype for 'usb_callback'
[-Wmissing-prototypes]
SR_PRIV int usb_callback(int fd, int revents, void *cb_data)
^
The current implementation is renamed to tcp-rigol as it seems to be
a Rigol proprietary protocol used only on Rigol VS5000 series.
A new tcp-raw implementation is introduced which simply carries raw SCPI
commands over TCP. It is probably a much more common protocol and it is
at least available on Rigol DS2000 series on port 5555.
Most messages from the DMM parsers are not hard errors, lower to
sr_dbg() so that the sigrok-cli output doesn't get cluttered (by default)
with debug output such as:
P1: 0.001100 V DC AUTO
sr: fs9721: Sync nibble in byte 0 (0x00) is invalid.
P1: 0.001100 V DC AUTO
(using -l 4 or -l 5 will still allow the user to see such messages)
Here is what the datasheet says about this:
"If judge bit is 1, it means frequency mode. If judge bit is 0,
it means duty cycle mode."
But this is plain wrong. Reality proves this is the other way around.
Depending on the chip, the limit value for the buzzer is between 25 and 35 Ω,
so this code set the limit for continuity to 25 Ω to be on the safe side.