PKG_CHECK_MODULES() checks for libusb-1.0 via pkg-config already, no
need to use a "manual" additional check via AC_CHECK_LIB() just to set
HAVE_LIBUSB_1_0 in config.h.
This helps with cross-compiling setups, among other things.
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 patch marks packet structures and their payloads as const.
This indicates to packet receivers that modifications to these are
not allowed. In general all pointers should be marked const unless
modification of the referenced data is explicitly allowed.
Hardware scanning creates an ftdi_context before attempting to locate devices
based on PID/VID. If no devices are detected, execution jumps to cleanup. The
context is freed with free(), instead of ftdi_free().
We cannot assume that the libftdi context is stored in a contiguous memory
region, and thus cannot use a simple free. Case in point, this situation is
identified by valgrind as a "definitely lost" memory leak.
Use ftdi_free() instead of a simple free() in hw_scan(). Valgrind no longer
complains about a memory leak in this area.
clear_instances() does not need any modification, as it correctly uses
ftdi_free().
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
commit 378abfeac6 tried to solve a bug where
the fx2lafw driver would print "Device came back" even if a timeout had occured.
It solved that issue, but inadvertently introduced a new bug:
"Device came back" would be printed even if no firmware upload was performed.
This is counterintuitive, as the device is only reset when a firmware upload is
performed.
There are three cases:
i) Firmware upload was successful
ii) Firmware upload failed
iii) Firmware upload was NOT needed
Each case warrants a separate message from the driver. Print the
following messages depending on the outcome:
i) "Device came back"
ii) "Device failed to renumerate"
iii) "Firmware upload was not needed."
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the new DRIVER_LOG_DOMAIN mechanism, where explicitly writing
the driver name in the message string is no longer required.
Thus:
- sr_err("fx2lafw: Something bad happened.");
becomes:
+ sr_err("Something bad happened.");
In either case, the log output is the same.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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!)
Just use the 'int dmm' + wrapper method that is used for all other
functions which need this information. There is no real need to
special-case the hw_dev_acquisition_start() API call here.
Having concentration as a unit is vague, as it can be expressed in
many ways. In the context of sigrok, concentration means a normalized
number from 0 to 1.
Document its meaning.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The rs9lcd parser, which is used for the RadioShack 22-812 does not use its
*info parameter, and therefore did not have a rs9lcd_info struct declared.
With recent re-factoring of the receive data callbacks, it became necessary to
pass a struct pointer. This made the RECV_DATA macro look like:
- RECV_DATA(RADIOSHACK_22_812, metex14)
giving the wrong impression that the RadioShack 22-182 uses the
metex14 protocol, which is not the case.
Create a dummy rs9lcd_info struct, and correctly identify the parser
as rs9lcd in the RECV_DATA macro:
+ RECV_DATA(RADIOSHACK_22_812, rs9lcd)
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Not all drivers use subdrivers. The only reason the subdriver field was
introduced was to accomodate the model of serial-dmm.
The sr_dev_driver struct is available to the frontend. Exposing the subdriver
field creates the problem of exposing knowledge of libsigrok's internal driver
layout, even though the drivers are designed to be a flat list to the frontend.
Store the subdriver in the dev_context struct of serial-dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The global *di alias was used to keep track of the driver context.
It caused issues with trying to use several subdrivers at once, so
its use was obsoleted.
The correct context is preserved through different mechanisms, either
the *sdi pointer, or wrappers which pass the correct context.
The *di alias is no longer used, so remove it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Wrappers for hw_init, hw_cleanup, clear_instances, and hw_scan are needed for
each subdriver due to the nature of serial-dmm. These wrappers are implemented
as macros, in order to reduce the number of lines of code.
For each of those functions, we have a separate wrapper list, then we connect
them together in a first-class driver using a DRV macro, and yet another list
(the DRV list).
Instead of declaring those wrappers in separate lists, include them in the DRV
macro. This approach reduces the number of macro lists from five to just one.
From the perspective of adding a new subdriver, this also greatly reduces the
number of places needed to hook in a new device.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Store/use the receive_data() function and a pointer to the driver struct
in the dmms[] array. Use a ".subdriver" entry in the driver struct.
Use a macro to simplify hw_init() wrappers.
Declare dmm_info dmms as extern in protocol.h to prevent duplicate
symbol error from the linker.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
di was initialized as NULL. If no device covered by this driver
is used, di remains NULL. This causes a segmentation fault when
calling clear_instances().
Check for di being NULL.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Commit 785b9ff290 added libusb init into
sr_init() which can generate an error. In this case, the already
allocated struct sr_context would have leaked.