../src/hardware/appa-55ii/api.c: In function ‘scan’:
../src/hardware/appa-55ii/api.c:47:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/arachnid-labs-re-load-pro/api.c: In function ‘scan’:
../src/hardware/arachnid-labs-re-load-pro/api.c:62:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/atten-pps3xxx/api.c: In function ‘scan’:
../src/hardware/atten-pps3xxx/api.c:81:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/brymen-dmm/api.c: In function ‘scan’:
../src/hardware/brymen-dmm/api.c:89:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/cem-dt-885x/api.c: In function ‘scan’:
../src/hardware/cem-dt-885x/api.c:74:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/conrad-digi-35-cpu/api.c: In function ‘scan’:
../src/hardware/conrad-digi-35-cpu/api.c:45:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/demo/demo.c: In function ‘scan’:
../src/hardware/demo/demo.c:255:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/fluke-dmm/api.c: In function ‘fluke_scan’:
../src/hardware/fluke-dmm/api.c:64:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/gmc-mh-1x-2x/api.c: In function ‘scan_1x_2x_rs232’:
../src/hardware/gmc-mh-1x-2x/api.c:147:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/gmc-mh-1x-2x/api.c: In function ‘scan_2x_bd232’:
../src/hardware/gmc-mh-1x-2x/api.c:234:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/ikalogic-scanaplus/api.c: In function ‘scan’:
../src/hardware/ikalogic-scanaplus/api.c:69:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/tondaj-sl-814/api.c: In function ‘scan’:
../src/hardware/tondaj-sl-814/api.c:44:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
Some driver scan() functions only ever return a single device. For those it
is possible to slightly simplify the handling of the device list by
creating it on demand when the function returns.
Some drivers also have the following expression:
devices = g_slist_append(devices, sdi);
...
if (!devices)
...
This check will never evaluate to false so it is dropped as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
A common task during device scan is to add the newly discovered devices to
the instance list of the driver. Currently this is done by each driver on
its own. This patch introduces a new helper function std_scan_complete()
which takes care of this. The function should be called at the end of a
driver's scan() callback before returning the device list.
Doing this with a helper function provides guaranteed consistent behaviour
among drivers and hopefully paves the way to moving more standard
functionality directly into the sigrok core.
Another common task that every driver has to do for each device instance is
to initialize the device's driver field. So this is done in the new helper
function as well.
All drivers that can make use of the new helper are updated.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some drivers set the device instance list to NULL in their scan() callback.
This means the driver loses all references to any devices contained in that
list and their resources will be leaked. Drivers can't free the devices at
this point either since an application might still use a device on the
list. So the existing devices on the instance list need to remain
unmodified during the scan() callback, even if that means that there will
be duplicates on the instance list. Only an explicit invocation of
sr_dev_clear() by the application is allowed to free the devices on the
instance list and reset the list.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The link-mso19 driver currently iterates the device instance list of the
driver to get the device instance for which the callback is called.
But the device instance is actually passed to the callback as the cb_data
parameter, so just use that instead and remove the lookup loop.
Besides that the current lookup loop does not even compile either.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The link-mso19 open-codes the std_dev_clear() function and uses it as its
custom dev_clear() callback. The std_dev_clear() function is automatically
called if no custom dev_clear() callback is specified, so just drop custom
implementation and use the default.
This also fixes a memory leak where the link-mso19 driver did not properly
free its driver state struct in the dev_clear() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sdi is allocated using g_malloc0() which can never fail, in addition to
that sdi is already dereferenced before the check, which makes the check
useless. So remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Using "\s*" on BSD sed doesn't work the same way as on GNU sed, thus
yielding e.g. " 3.0.8" instead of "3.0.8" in a ./configure check, which
later prevents the Ruby bindings from being built.
Fix this by simply using exactly one space in the sed invocation, since
swig seems to always use just one space there anyway.
Tested on Mac OS X, FreeBSD, and Linux.
This closes bug #800.
HP instruments predating the 488.2 and SCPI standards do not
necessarily have a SCPI-compliant command set. The HP6630A series of
supplies is one such example.
While scpi-pps is flexible enough to accomodate almost any command
syntax given the right profile, it still assumes that "*IDN?" is the
correct question to ask the instrument. Since older HP gear instead
responds to "ID?", this assumption is no longer true.
Thus sr_scpi_get_hw_id() is not appropriate for these instruments, and
the shadow driver added here only replaces that function call, while
reusing the rest of the existing logic. The extra noise is necessary
in order to propagate this through the .scan member of the driver.
Use the standard connection_id field from the struct sr_dev_inst for
storing the device address rather than using the custom address field in
the driver state struct. This makes things more consistent with the
framework.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The sigrok core needs a list of all available drivers. Currently this list
is manually maintained by updating a global list whenever a driver is added
or removed.
Introduce a new special section that contains the list of all drivers. The
SR_REGISTER_DEV_DRIVER() and SR_REGISTER_DEV_DRIVER_LIST() macro is used to
add drivers to this new list. This is done by placing the pointers to the
driver into a special section. Since nothing else is in this section it is
known that it is simply a list of driver pointers and the core can iterate
over it as if it was an array.
The advantage of this approach is that the code necessary to add a driver
to the list is completely contained to the driver source and it is no
longer necessary to maintain a global list. If a driver is built it will
automatically appear in the list, if it is not built in won't. This means
that the list is always correct, whereas the previous approach used ifdefs
in the global driver list file which could get out-of-sync with the actual
condition when the driver was built.
Any sr_dev_driver structs that are no longer used outside the driver module
are marked as static.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Most drivers have a forward declaration to their sr_dev_driver struct at
the beginning of the driver file. This is due to historic reasons and often
no longer required. So remove all the unnecessary forward declarations.
Some drivers still require the forward declaration, but only reference the
driver struct from within the driver scan() callback. Since the driver
struct is passed to the scan callback replace the references to the global
variable with the local parameter. In some cases this requires adding the
parameter to some of the helper functions that are called from the scan()
callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Binary block data is specified in IEEE 488.2. First character is '#',
followed by a single ascii digit denoting the the number of digits needed
for the length specification. Length is given in bytes.
This allows drivers to replace retrieval of comma separated ASCII values
with binary formats. See bug #791.
The method accepts strings with numbers in scientific or normal notation,
e.g. -1.25 or 3.37e-6. The numeric range is limited by the sr_rational
range, i.e +-9.2e18, resolution is ~19 digits.
To capture more than 16MSamples the hardware run length encoding option
must be enabled, or captured data present errors.
RLE encoding/decoding is done in hardware. Data streamed to the USB interface
is not encoded.
This commit enables RLE encoding for captures longer than 16MSamples.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
This commit expands support for acquisition using an external clock,
now allowing the user to select the clock edge.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
For low sampling speeds (up to 25MHz) DSLogic offers a streaming mode where
samples are sent directly to the USB interface, like a fx2lafw device.
For high sampling speeds (up to 400MHz) only buffer mode is supported.
This commit allows the user to set which mode should be used. The configuration
is done by using SR_CONF_CONTINUOUS.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
SR_CONF_CONTINUOUS is used to check if a device supports continuous sampling
or not. As such, the type boolean is better suited.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
The DSLogic provides two FPGA images: one for 3.3V and the other for 5V logic.
The DSLogic Pro allows to set an arbitrary voltage threshold via USB command.
This commit adds support for the DSLogic to load the FPGA image according to
an user-selectable voltage threshold.
For the DSLogic Pro, one of two fixed voltage thresholds are set, depending on
the user-selected value.
Tested with DSLogic and DSLogic Pro.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Tested-by: Andrew Bradford <andrew@bradfordembedded.com>
This commit implements DSLogic trigger functionality.
The following triggers are working:
- trigger on rising edge
- trigger on falling edge
- trigger on any edge
- trigger on logic one
- trigger on logic zero
Pre-trigger capture ratio is also working.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Tested-by: Andrew Bradford <andrew@bradfordembedded.com>
The demo device has support for specifying the number of analog and logic
channels it should have. Currently this does not work correctly if one of
them is set to zero. Being able to set the number of channels to zero for
one of the channel types is quite useful for corner case testing though.
Make the following modifications to handle it correctly:
1) If the channel count is zero no channel group for that channel type
should be created since a channel group needs at least one channel.
2) Drop the check if logic_unitsize is less or equal to zero in
prepare_data() since this condition will always be true if the number of
logic channels is zero and it is not possible to create a demo device with
only analog channels.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
zip_append_analog() does not free most of the memory it allocates. Address
this by moving all sanity checks that do not rely on anything else at the
beginning of the function before any allocations are done. And then make
sure to properly free all allocated memory on all paths leaving the
function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Uwe Hermann
Lars-Peter Clausen
Aurelien Jacobs
Alexandru Gagniuc
Marcus Comstedt
George Hopkins
Stefan Brüns
Diego Asanza