When the processing of columns of text lines detected errors, the loop
was aborted and the routine was left, but allocated resources were not
freed. Fix the remaining memory leaks in the error code paths.
The constant at the top of the source file is the number of samples in a
datafeed submission chunk. The previous implementation erroneously made
it the size in bytes. There is no need to round down the buffer size
according to the unit size.
The previous implementation sent one sigrok session datafeed packet per
processed CSV line. This is rather inefficient for the CSV input module,
and triggers a dramatic performance loss in the srzip output format.
Communicate up to 128K samples within one datafeed packet. This fixes
bug #695.
Factor out repeated calculation of the unit size which is derived from
the channel count. Fix a minor memory leak in an error path while we are
here. (Other memory leaks in rare error paths remain with this commit.)
Suggested-By: Elias Oenal <sigrok@eliasoenal.com>
On the Windows platform it appears to be popular to _not_ terminate the
very last line in a text file. Which results in an unmet constraint in
the CSV input module and an internal exception in PulseView which aborts
program execution.
Cope with the absence of the text line termination sequence at the very
end of the input stream. Keep all other checks in place, such that only
completely received text lines get processed.
This fixes bug #635.
"Document" the current state of the implementation in the CSV input
module's source code. Discuss how text handling is non-trivial, which
approaches are available and how they have drawbacks.
Mention the lack of support for the import of analog data as well.
The CSV input module supports variable length end-of-line encodings
(either CRLF, or CR, or LF). When a bunch of accumulated text lines got
processed, do skip the corresponding number of characters after the end
of the last processed line.
This fixes one of the issues discussed in bug #635.
The input module runs receive() and end() invocations which end up
calling process_buffer(). It's perfectly legal to call the process
routine with an empty accumulation buffer, especially when the process
routine was called from end().
This fixes a condition where PulseView raised a fatal error at the end
of a completed successful import.
Reported-By: Sergey Alirzaev <zl29ah@gmail.com>
Move an independent test for single/multi column operation out of a code
path that checked for and then processed text lines. This commit does
not change behaviour, but prepares a subsequent commit.
Factor out a magic string literal which held a delimiter set yet could
be mistaken for an (assumed) fixed termination string. Concentrate the
determination of the end-of-line text encoding as well as the resulting
set of possible deliminters in one nearby location. The symbolic name
for the delimiter set eliminates the doubt on its purpose.
Handle the case when the sample data memory was filled and has wrapped
around during acquisition. Download the respective part of the data
which is reliably available, only skipping a single 1KB row which might
contain either old or new data while it's not certain which it would be.
This will be essential when triggers later become available. Right now
it copes with user requests for sample counts that exceed the total DRAM
capacity. Instead the maximum available amount of data is provided.
Of course acquisition no longer gets stopped when the end of DRAM is
reached.
Correctly determine the size of a download chunk for the last DRAM row
that's involved in the recent data acquisition.
This commit is based on work done by jry@.
This addresses bug #838 (trailing garbage).
It's assumed that the previously downloaded excess data was "swallowed"
by the sample count enforcement logic that was applied earlier, so the
(remainder of the) issue could have gone unnoticed, unless some other
termination condition than sample count was used.
Configure the samplerate clock and channel count during acquisition
start in identical ways for 50MHz, 100MHz, and 200MHz modes.
This part was inspired by work done by jry@ yet was addressed in
different ways (no exception, do everything in every mode the same way).
Eliminate a portability issue in the previous implementation. Make sure
to send the configuration bytes in the correct order to the hardware.
Don't typecase a struct reference to a bytepointer and hope that the
internal memory representation might fit the external hardware's idea.
Add a comment about sample memory organization in a central spot. This
concentrates knowledge which otherwise would be spread across several
locations all over the driver's codebase, yet is essential to have at
hand during maintenance.
All of the information was determined/updated by jry@ with the help of
Ondrej at Asix when he did lots of fixes and improvements to asix-sigma.
The Asix Sigma hardware does not support a sample count limit. Instead
this optional input parameter gets mapped to a sample time, and some
slack for hardware pipelines and compression gets added. When data
acquisition completes and sample data gets downloaded, chances are that
there is more data than requested by the user.
Do enforce the optional sample count limit. Stop sending data to the
sigrok session when the configured number of samples was sent.
This commit is based on work done by jry@.
This fixes bug #838.
Enhance how the data acquisition is stopped. Wait for the hardware to
flag the successful completion of data retrieval as well as flushing
through hardware pipelines.
Use symbolic identifiers for the mode register's fields (for read as
well as write access).
This commit uses part of a code update to better match the documentation
done by jry@, but not all of it to reduce the size of the commit.
Minor adjustment for improved readability. Don't hide assignments in
variable declarations. Move initialization of some variables closer to
related evaluation or subsequent processing. Break a complicated looking
roundup expression into several short steps.
Fix how the READ_ID register index was passed to the hardware access.
Addresses are sent in nibbles, so shift by eight is wrong here. No harm
was done, as the register's index is zero.
The Asix Sigma driver is aware of three firmware images, which are
required for acquisition with up to 50MHz, 100MHz, and 200MHz. The
previous implementation always downloaded the corresponding firmware
image whenever the sample rate has changed, which was redundant.
Skip the download when the new samplerate uses the same firmware as the
previously selected samplerate did. This results in faster responses in
the GUI when the samplerate selection changes.
Move assignments out of the variable declaration block for improved
readability while we are here.
The hardware provides captured data at a maximum rate of 16bits per 20ns
(50 MHz). For samplerates of 100 and 200 MHz one individual 16bit entity
contains multiple samples for a reduced number of channels. The bits of
several sample points are interleaved within the 16bit entity.
This commit is based on work done by jry@ who fixed a lot of issues with
the help from Ondrej at Asix.
This fixes bug #840.
Adjust the interpretation of acquired sample data such that regardless
of 50/100/200MHz samplerate the assignment of LA pins to sigrok channels
remains stable.
Introduce helper routines to access the sample data that is provided by
the ASIX hardware, as well as the buffer which accumulates logic data
before it gets sent to the session's datafeed.
This hides endianess issues from call sites, and prepares access to
memory layout which varies with sample frequencies.
This commit is based on work done by jry@.
This works around bug #359. Triggers currently are not operational for
Asix Sigma. Don't claim support in the driver so that UIs won't use the
feature. Yet allow research in this issue, by concentrating the switch
for the feature's support in a central location.
Add/update a comment and unobfuscate an error code path while we are here.
Both the .c and the .h file declared the same identifiers for USB
properties of ASIX hardware with identical values. Remove the .c
incarnation and keep the .h content, as the names are used in api.c
as well as protocol.c sources.
Introduce a separate routine which maps sample counts and sample period
to an elapsed sample time after which acquisition shall get stopped.
Add some more time to make sure the most recent captured data has passed
the hardware pipeline and is available for download.
This commit is based on work done by jry@.
When "tsdiff < EVENTS_PER_CLUSTER" we don't want "tsdiff - EVENTS_PER_CLUSTER"
(a negative number) to be treated as (int).
Submitted-By: jry <jrysig@gmail.com>
[ gsi: massaged for mainline submission ]
The resistance values of some DMMs were incorrectly reported due to a
missing factor of 10 in the calculations.
Tested on Voltcraft VC-920/VC-940 and Tenma 72-9380A/72-7730/72-7732.
Bump the number of supported logic channels from 8 to 128. This is
mostly motivated to test the 64 channels limit which some of the
components/subprojects of the sigrok project might have (input/output
modules, user interfaces).
Only automatically enable the first 8 of the 128 total logic channels,
i.e. default to the previous behaviour. Prepare to only enable part of
the set of analog channels, but stick with their being active by default
as well.
Factor out the choice for the default logic pattern, too. This allows
for easier adjustment of the default configuration, when settings are
concentrated in a single spot.
Extend the demo driver, add another waveform choice for logic channels.
Create a "cable squid" logo representation which occupies a large number
of channels.
This pattern occupies 128x128 pixels. Unlike the 'sigrok' pattern it
gets repeated when more channels are involved, but is not shifted in the
repetition.
Old:
ut71x: Applying exponent -12, new value is 0.000000.
P1: 1.500 nF AUTO
P1: 1.500 nF AUTO
New:
ut71x: Applying exponent -12, new value is 1.5e-09.
P1: 1.500 nF AUTO
P1: 1.500 nF AUTO
This fixes bug #700.
This is a (hopefully temporary) workaround for the
SR_CONF_CAPTUREFILE mechanism. The value for
vdev->capturefile is set by this, however only once
via stream_session_data().
During stream processing in stream_session_data(),
capturefile may receive new values - e.g. when there
are multiple logic files or if there is analog data.
With that, the initially set capturefile is overwritten.
When re-loading the file, we are then running into
issues because we don't know what the initial value was.
As all .sr files use "logic-1" by default and, we
simulate the behavior of stream_session_data() and
assign this name to capturefile if there are logic
channels present.
With this change, all three kinds of files reload
as expected: logic only, analog only and mixed signal.
For this reason, it's a short-term fix for #944.
The handling of the digital channels for this series is somewhere
between that of the DS1000D series (PROTOCOL_V2) and the MSO1000Z
(PROTOCOL_V4).
The :LA command set is similar to that of V4, but the LA data has to be
requested with :WAV:SOUR:LA and arrives in interleaved form like V2.
None of these changes should affect other models. They only affect the
case of PROTOCOL_V3 with digital channels, which occurs only for the
MSO2000A series.
'i' was iterating in steps of unitsize. However, the destination array
was also indexed with it, but it is of u8 type. Let 'i' run bytewise and
only multiply with unitsize when we need it.
This fixes parts of bug #844.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
'j' is the loop variable for channels, not 'i'.
This fixes parts of bug #844.
Reported-by: Maxim Sloyko <m.sloyko@gmail.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
src/output/csv.c: In function 'dump_saved_values':
src/output/csv.c:461:6: warning: format '%lu' expects argument of
type 'long unsigned int', but argument 3 has type 'uint64_t' [-Wformat=]
ctx->sample_time, ctx->value);
^
Fixes#933.
We'd already had this problem elsewhere and thus have this wrapper function
that does this where necessary. It just wasn't in use on these two call sites,
which was causing timing problems when used over tcp-raw or VXI transports.
With trigger enabled, and with PulseView, a second (or more) acquisition
starts immediately instead of blocking. It's mandatory to try several times
to have a correct behavior.
According to http://mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf section 2.3.1
p.8, the Openbench Logic Sniffer must be reset before each arm command.
This fixes bug #809.
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Openbench Logic Sniffer reset is a little more complex than a simple send.
To avoid code duplication, this patch adds a new function dedicated to
this task.
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Increasing the chunk size from 512ksamples to 4Msamples leads to
slightly faster session file loading from sigrok session (*.sr) files
in frontends, while not looking too "chunky".
The performance increase is not really massive, but still noticeable.
A further increase to, say, 10 or 100Msamples shows no further
noticeable improvements.
This changes the fx2lafw code to only enable the wide_sampling (16bit)
method, if at least one of the higher eight channels is enabled. This
has the benefit, that we can use higher samplerates on 16bit LA
devices if we use only the first eight channels.
The wide sampling is also enabled if we have one or more analog
channels.
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
I've seen the following output from sigrok-cli:
CH1: 478.720 mV
CH1: -514 mV
CH1: -0 V
I added some debug, and it seems like the digits value isn't reset
to the actual value after calling sr_analog_si_prefix_friendly():
using 6 digits
value2 0.478720 digits 6
value2 -0.513536 digits 3
value2 -0.487424 digits 0
This commit fixes this by resetting the value to the actual value before.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
devc->step is not reset on acquistion start, so acquisition
starts with a different value every time. Thats annoying when
using the demo driver to debug sigrok, so lets make sure that
it's reset to 0.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
When using SCPI over serial (over USB), we want the header without waiting
for the terminating newline, as otherwise the transfer may time out.
sr_scpi_get_data() will block until the message is complete.
Lowlevel access functions should not alter the data. sr_scpi_get_string(),
which is called by most highlevel access functions, strips newlines
in a central place, and is only fed with data which contains newlines
as a final terminator.
IEEE 488.2 definite length blocks may contain arbitrary data, thus the
payload up to the provided length should be passed unaltered.
Track if the last received character is a newline, which can be used
by sr_scpi_get_string() and its callers to determine if the response
is complete.
g_get_monotonic_time() returns current time in microseconds, use the same
granularity for storing the read timeout.
There is also no need to check the timeout if data has just been read.
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
The output was wrong for all frequencies but 1 Hz, 1 kHz, 1 MHz and 1 GHz.
With this changes, the output may still be off due to rounding, but will
be correct as to the shown accuracy.
When nothing was received in a read attempt, we need not adjust the
buffered data's read position nor the glib string object's size. Skip
any processing for empty input, just keep checking for timeouts.
Routine sr_scpi_get_data() checks for free space in the receive buffer,
and resizes the buffer when free space drops below a threshold. The
previous logic assumed that the resize and the read logic would interact
in some specific way to achieve the desired operation.
Adjust the buffer resize such that more free space is pre-allocated, yet
the payload size of the buffer is not affected. This eliminates the
dependency of the optional resize logic from subsequent activity for
reception of data that is non-optional.
Add comments while we are here, outline the steps taken in the
sr_scpi_get_data() routine.
Phrase the logic which checks the use of analog channels and digital
pods in more generic terms. Place a comment about the contraints' being
potentially dependent on the specific HMO model. This implementation
should lend itself better to future adjustment (HMO1002?).
An internal libsigrok implementation detail prevents partial submission
of logic data for different channel groups in multiple calls. Instead
one logic packet needs to be sent in a single call, which combines data
for all channels.
Introduce a logic data storage which folds samples from several channel
groups that were received at different points in time into a combined
memory layout of larger unitsize. Stick with the former shortcut of
passing on the input bytes directly when only the first digital pod is
used during acquisition.
This change correctly maps data from the second pod to channels D8-D15.
The previous implementation only added one of the digital channels to
the list of enabled channels that are involved in the acquisition (the
first one that was found). This means that when the set of used digital
channels spans more than one pod/group, the second pod will never be
read from.
Make sure to enable one digital channel per pod/group, such that
acquisition will retrieve data from all involved input sources.
Add comments while we are here. Mention how the different setup, check,
start, and receive routines which are spread across several files do
interact to achieve acquisition.
The previous implementation used to put FRAME_BEGIN and FRAME_END
markers around each received chunk of samples, while those chunks
correspond to a single channel (analog) or a group of eight channels
(digital) each. In other words, the hameg-hmo driver had provided a
multiple of the requested frames, and those frames were incomplete.
Make sure to only send FRAME_BEGIN before the first channel's data,
and FRAME_END after the last channel's data of a frame. Thus make
sigrok frames exactly match the scope's frames.
Add some comments on the frame marker and the acquisition stop logic
while we are here.
Configure the scope to the host's native endianess before downloading
acquisition data from analog channels. This unbreaks operation on those
models which default to a representation which differs from the host.
Undo the change which skips management activities when no data was
received. This change breaks the current implementation, and needs to
get deferred until a delicate interaction between the resize and the
read logic has been eliminated.
Replace a C library strcspn(3) call with the more portable glib
g_strstr_len(3) routine. This is possible since a single separator
is searched for, no actual "set of characters" is involved.
As a byproduct, this eliminates a "late" reference to 'cnt' at the
bottom of the routine, after the value was assigned in a rather distant
location at the top of the routine. The cost of strlen() should be
acceptable for a buffer with a single digit total length.
Replace C language string operations with their glib incarnations for
improved portability. Prefer a common sigrok float conversion routine
over a DIY implementation.
The specific packet layout puts constraints on the parse logic (case
sensitive comparison, order of comparison). Fix a comment that made no
sense before, and better reflect that there are two constraints.
Slightly rephrase the SCPI code which parses the responses that carry
(binary) data blocks. Be explicit about NUL termination when parsing the
leading length spec in the response, obsoleting the array initializer.
Add lots of comments and group source code lines to better reflect
what's happening from the protocol's perspective.
Fix the returned error code in the path which reads responses of
excessive length in chunks. The previous implementation detected errors
but always returned code 0 (success).
When nothing was received in a read attempt, we need not adjust the
buffered data's read position nor the glib string object's size. Skip
any processing for empty input, just keep checking for timeouts.
Drop an initial assignment to a variable which never takes effect.
Add braces around the body of a more complex if block. Separate routines
from each other by exactly one empty line.
When the channel state is retrieved, query the pre-set byteorder for
SCPI data blocks as well. When samples get retrieved during capture,
support float representations in either big or little endian format.
This commit unbreaks devices which operate in BE format by default
(tested with HMO2524). It keeps working with LE format as before. For
devices which don't support the byteorder query or return unknown
responses, LE format is assumed for backwards compatibility. The
device's byteorder is only queried and never set. This makes the
commit least intrusive.
A comment mentioned that the models HMO2524 and above support 16 digital
channels (and thus have two pods for the probes). Move those models to a
section that declares the respective features, including trigger support
on the upper digital channels.
Model detection and reflection of supported channels was tested on HMO2524.
Commit db81fbb582 made sure to release a potentially previously
allocated list of enabled channels before (re-)building the list in the
current invocation of acquisition start.
This commit frees the memory in the error path near the failed creation
already, which reduces the period of time where unused resources are
held, and eliminates a memory leak when acquisition is not stopped after
failed start.
Both approaches can coexist. Freeing an empty list is perfectly fine.
Fix the code which registers the name of the second pod for digital
probes. The previous implementation registered the first pod twice, and
lost the reference to the second pod. No harm was done, none of the
supported models declared support for two pods so far.
Factor out a channel to group mapping in the registration of digital
channels, while we are here.
The former DER EE DE-5000 driver was a very thin wrapper around the
ES51919 LCR meter chipset. None of its source was specific to the
deree-de5000 device. In fact it contained code for all currently
supported LCR meters, and it's expected that all LCR meters which
will get added in the future will fit in as well.
Follow the serial-dmm model. Rename the src/hardware/deree-de5000/
directory to serial-lcr/. Update the configure logic. Although the
source directory and the configure option are named serial-lcr, the
LCR meter still is used by specifying the "deree-de5000" device driver
(which just happens to reside in the serial-lcr driver sources, among
others).
Introduce an asycii.c source file (modelled after metex14.c) which
implements support for the 16-byte protocol of the ASYC-II multimeter
chipset (RX only, when the PRINT button was pressed).
The "deree-de5000" driver is a very thin wrapper around the ES51919
chipset. We expect more models from other vendors to use that same
support code.
Model the registration of vendor/model combinations after the serial-dmm
approach. Register the DER EE DE-5000 device as the currently only
member in a list of drivers which all use the ES51919 chipset (no model
specific routines are registered in the absence of support for other LCR
meter chips).
This commit does not change the driver's behaviour nor the set of
supported hardware. It prepares the addition of more drivers in the
future.
Factor out identical comments on the UART bitrate of ES519xx based
multimeters. These probably got copied from the first item as of 2012
when new items were added in 2014 (the added devices were from the
same vendor and rebadged).
Expand on the fact that the bitrate still is within spec, and does not
harm at all. Strictly speaking the comment could get dropped.
The previous implementation seems to have added drivers in their "order
of appearance". Start sorting the rather long list, to simplify several
tasks: Add new entries as more drivers get written, find existing items
during research, identify and compare similar models during maintenance.
As a byproduct, there will be no doubt about where to put things during
future work :) and duplicates will be spotted immediately.
This commit puts 'bm25x' meters into one group. And comments on the sort
order and motivation for sorting the table.
Commit 6bcb3ee876 introduced initial support for the Cyrustek ES51919
chipset. Its setup_channels() routine used to init a variable to assume
failure, then a loop added channels and changed the value to success.
Commit 5e23fcab88 changed channel setup to never fail, but kept the
initialization with an error code. Which prevented the operation of
successfully detected LCR meters.
Remove the no longer needed variable, instead always return success from
an operation which cannot fail.
Fixes: 5e23fcab88 "Simplify channel creation."
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Add another DMM entry for Peaktech-3330, which is based on the FS9721
chipset. Support was tested with the CP210x based USB cable.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Since tastes and requirements might differ, introduce support for a
user specified character set in the construction of ASCII art graphs
of signal levels. The syntax is "charset=<low><high>[<fall><rise>]",
the default remains backwards compatible with existing consumers.
In comparison to assuming a fixed character set, this change addresses
several distinct aspects:
Users can adjust the output for "higher visual contrast", or "straight
lines" instead of dotted patterns, or "increased difference in height"
for low and high signal levels, or "filled" (block like, "wall of text")
appearance of periods with high levels. User adjustable characters are
needed, as no single fixed set can satisfy the differing expectations.
Perception of the output heavily depends on specific terminals and fonts
in use.
Then there is the issue of levels versus edges, and how their timing
relates. By default edges are drawn at a point in time where the signal
was sampled and was deteremined to already _have_ changed and have
settled to the new level, which means that the position of edges in the
resulting graph might be off by up to one sample period. Strictly
speaking, the available set of samples only contains levels, and does
not hint where exactly an edge might have occured. Though this might be
considered rather nitpicky, representing the graph without edges does
better reflect the input data, and might simplify postprocessing.
Compare the previously only supported format (still the default, -O ascii):
1:...................................................../""""""""""""""""""""
1:""""""""""""""""""""""""""""""""\.........................................
1:..........................................................................
to those example alternatives:
$ sigrok-cli -i file.sr -O ascii:charset=_\"\\/
1:_____________________________________________________/""""""""""""""""""""
1:""""""""""""""""""""""""""""""""\_________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_\"
1:_____________________________________________________"""""""""""""""""""""
1:""""""""""""""""""""""""""""""""__________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_^
1:_____________________________________________________^^^^^^^^^^^^^^^^^^^^^
1:^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^__________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_M
1:_____________________________________________________MMMMMMMMMMMMMMMMMMMMM
1:MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM__________________________________________
1:__________________________________________________________________________
$ sigrok-cli -i file.sr -O ascii:charset=_X
1:_____________________________________________________XXXXXXXXXXXXXXXXXXXXX
1:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX__________________________________________
1:__________________________________________________________________________
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
We now require the use of the latest fx2lafw firmware which uses the
same USB VID/PID (1D50:608E) for the Hantek 6022BE and the variants
and rebadges of that device (e.g. the SainSmart DDS120).
The variants can be distinguished via the USB product version field.
This allows much faster and configurable sampling rate, and faster
reaction to function switch.
This also gives a more repeatable job ordering and more reliable
query/reply association.
Fix the array size check in the sigma_write_register() routine. The
'len' parameter specifies the number of bytes to write, while the 'buf'
array holds one nibble per array item.
The previous implementation (commit e8686e3ae3) switched to a
constant size and made the buffer large enough so that no existing
request would exceed the buffer, fixing an overflow that was present
before that commit. But the most recent size check was incomplete and
might erroneously succeed for larger amounts of write data.
It's assumed that the issue which gets addressed here never occured in
practice. The constant-size buffer could hold up to 39 bytes of input
data in their transport representation, while the largest data that was
passed to the write routine is six bytes (trigger LUT params).
Fixes: e8686e3ae3 "asix-sigma: Avoid use of variable length arrays"
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
The driver internally implements the "limit samples" feature by means of
the "limit sample period" approach. Determination of the corresponding
period of time for captures depends on the sample rate as well as the
maximum sample count, and thus needs to be re-done when either setting
changes.
Introduce a "limit_samples" variable so that the value is available when
needed later. As a byproduct the parameter can be retrieved now (get).
Add comments to the sigma_set_samplerate() routine's sections, since
quite a bit is happening there, and interacts with other locations.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Commit 2c9c0df86e removed the sentinel from the samplerates[] array,
but did not adjust the test which checked whether a rate is listed in
the set of supported rates. This could result in an out-of-range access
beyond the array's last item.
Fix the "listed?" check after iterating the table of supported rates.
Cope with either presence or absence of a sentinel in the array.
Address some more style nits while we are here. Rename an identifier
for a local variable which unintentionally might suggest that it would
be a preprocessor macro (all-caps). Reduce redundancy in data type
references as well as in the determination of the array size.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
The current implementation of the ASIX Sigma firmware download contains
comments which express uncertainty. Rephrase them, no magic is involved.
Discuss the polarity of the CCLK hardware signal. Which shall eliminate
potential concerns in future reviews or maintenance.
This commit only updates comments, and does not change behaviour.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
Don't show duplicate lines (per default) such as
sr: resource: Failed to locate 'saleae-logic16-fx2.fw'.
sr: resource: Failed to open resource 'saleae-logic16-fx2.fw'.
The first one is now an sr_dbg() instead of sr_err().
Also, mention that a higher loglevel will give more information as to
where the backend is looking for resources / firmware files.
This fixes bug #806.
This change tweaks the CSV output module to change the label
setting from on/off to units/channels/off, where channels is the old
on behavior, and units uses the meaning field to generate the column
label - except for the generated Time column, which uses the label from
the X axis when it's generating gnuplot output.
- It now handles more than one analog value correctly - at least from the
demo driver.
- Add column headers from channel names.
- Add a row dedup capability.
- Add a sample time column.
- Add a frame end formatting (for gnuplot).
- Made almost all formatting controllable or at least optional.
- Fix it so we can mix analog and digital values.
- Add outputting a gnuplot script for the data.
- Count actual channels, not just mine, to find end of sample.
- Add trigger option (untested).
The default so far was 0, which meant there would be no significant
digits at all, yielding results that looked strange/wrong to the user.
Long-term all remaining drivers should be fixed to use the actual,
correct digits and spec_digits values according to the device's
capabilities and/or datasheet/manual. Until that is done, a default
of digits=2 is used as a temporary workaround.
This fixes the remaining parts of bug #815.
Here's a patch to "Ignore requests to set coupling for the Hantek 6022BE",
this clears the LIBUSB errors for me.
Also in the patch:
- There is a crash because config_list() can be called with sdi == NULL.
This can be reproduced by doing:
"sigrok-cli.exe --driver hantek-6xxx --show"
- There seems to be a very unsafe loop in config_set() when setting COUPLING;
the coupling vector is assumed to be zero terminated, but is not declared
as such.
Note: The same issue is present also for other hardware, at least for
hantek-dso/api.c. The patch is only for hantek-6xxx though.
There were issues when using non-power-of-two data sizes with e.g.
the Hantek 6022BE device. For example, on Windows the acquisition would
simply hang and never complete:
hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_ERROR received 0 bytes
The issue was reported by Erik Montnemery on the mailing list, the
original patch was posted by "mmark" here (thanks!):
http://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911729/#msg911729
The issue has been verified by me on Windows and Linux, and also that
this change does indeed fix it (tested Hantek 6022BE and Sainsmart DDS120).
Neither PulseView nor sigrok-cli hang anymore on Windows, and on Linux
the log messages suggest improvements as well:
-hantek-6xxx: data_amount 712
+hantek-6xxx: data_amount: 200 (rounded to power of 2: 512)
-hantek-6xxx: receive_transfer(): calculated samplerate == 2327ks/s
-hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_OVERFLOW received 512 bytes.
+hantek-6xxx: receive_transfer(): calculated samplerate == 1969ks/s
+hantek-6xxx: receive_transfer(): status LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED received 512 bytes.
This fixes bug #821.
Some functions in std.c were using
const char *prefix = sdi->driver->name;
but were called from input/output modules as well (which don't have
a "driver" field).
As a temporary workaround, use "unknown" as prefix in such cases until
a more permanent solution is implemented.
This fixes bug #813.
This fixes the following build issue on OSX:
Undefined symbols for architecture x86_64:
"_sr_drivers_init", referenced from:
_sr_init in backend.o
This closes bug #802.
When a meter display 105.2 kΩ, libsigrok will return 105200 Ω
but it is really valuable to know that the last 2 digits are not
significant, so encoding.digits should be set to -2.
This would allow a sigrok client to display 105200 as 105.2 k
instead of 105.200 k.
055804e89e changed the outgoing
SCPI message termination by always adding a newline. This results
in the following log output:
sr: [00:00.003102] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.005648] scpi_vxi: Successfully sent SCPI command: '*IDN?
'.
sr: [00:00.005931] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
This patch restores the previous unterminated SCPI message logging:
sr: [00:00.005462] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.007515] scpi_vxi: Successfully sent SCPI command: '*IDN?'.
sr: [00:00.007860] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
As it's located in the general logging mechanism, we deal with any
additional (and unwanted) newlines this way.
This single object also contains the sr_drivers_init function, that will
always be referenced. That ensures that the drivers object files won't
be optimized out during static linking due to the fact that they are
not referenced directly.
This addresses (parts of) bug #802.
These functions were only used in the SR_DF_ANALOG_OLD case,
whereas the SR_DF_ANALOG case already used functions and lists
from src/analog.c.
This closes bug #636.
When config_list() gets NULL as sdi, it must return driver opts.
Some drivers, including zeroplus, don't check sdi and return both
driver opts and device opts.
Now that std_serial_dev_acquisition_stop() has the same signature as
the sr_dev_driver dev_acquisition_stop() callback it is possible to remove
the wrapper functions and use std_serial_dev_acquisition_stop() directly
has the callback function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All callers of std_serial_dev_acquisition_stop() currently pass the same
callback for the dev_close_fn parameter as the dev_close callback of their
sr_dev_driver struct. Remove the dev_close_fn parameter and invoke the
drivers dev_close() callback directly. This simplifies the API and ensures
consistent behaviour between different drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All callers of std_serial_dev_acquisition_stop() currently pass sdi->conn
for the serial parameter. And the other std_serial helper functions already
require that the conn field of the sr_driver_inst passed to the functions
points to the sr_serial_dev_inst associated with the device.
Modify std_serial_dev_acquisition_stop() to follow the same pattern and
remove the serial parameter. This simplifies the API and ensures consistent
behaviour between different drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some of the standard helper functions take a log prefix parameter that is
used when printing messages. This log prefix is almost always identical to
the name field in the driver's sr_dev_driver struct. The only exception are
drivers which register multiple sr_dev_driver structs.
Instead of passing the log prefix as a parameter simply use the driver's
name. This simplifies the API, gives consistent behaviour between different
drivers and also makes it easier to identify where the message originates
when a driver registers sr_dev_driver structs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All drivers with the exception of pce-322a pass their dev_close callback to
std_serial_dev_acquisition_stop(). The pce-322a passes std_serial_dev_close()
which is also called from its dev_close() callback and replicates the other
functionality of its dev_close() callback directly in
std_serial_dev_acquisition_stop().
Refactor this to pass the dev_close callback function directly to
std_serial_dev_acquisition_stop(). This makes sure that the driver is
consistent with other drivers and also removes duplicated code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that driver the does not reset all the limit
statistics in acquisition_start().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that the driver does not reset the limit
statistics in acquisition_start(). It also makes the time limit work, which
previously was only a stub implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that the driver does not reset the limit
statistics in acquisition_start(). It also makes the time limit work, which
previously was only a stub implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The version field in the norma-dmm driver state struct is initialized, but
never read and the same information is also already available in the
sr_dev_inst struct version field. So remove it to simplify the code.
This allows to get rid of the custom dev_close() callback and just use the
standard std_serial_dev_close() instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
../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>
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>
0 is a valid index for a channel. Using it as the value for the terminating
entry of analog_index_map causes zip_append_analog() to falsely assume that
no channel was found when a packet for a channel with index 0 was received.
This prevents the data for the channel to be added to the sigrok session
file.
Instead use -1, which is not a valid channel index, as
the terminating entry value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Now that the signature of std_init() matches that of the driver init()
callback we can remove all wrapper functions around std_init() and use it
directly as the init() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
std_init() checks if the pass in struct sr_dev_driver is non-NULL and
prints a error message and returns an error if it is NULL.
std_init() is exclusively called from driver init() callbacks for which the
core already checks if the struct sr_dev_driver is non-NULL before invoking
the callback. This means the check in std_init() will always evaluate to
false. So drop this check.
This also means that the prefix parameter that was used in the error
message is no longer needed and can be removed from the function signature.
Doing so will make the std_init() function signature identical to the
init() callback signature which will allow to directly use it as such.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The std_init() callback has the order of the first two paramters opposite
to the init() callback. This is primarily due to historical development.
Since the std_init() function is usually called from a driver's init()
callback aligning the order will allow direct register pass through rather
than having to swap them around. It also allow to eventually use the
std_init() function directly as the init() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The zeroplus-logic-cube driver uses libusb_get_device_list() but neglects
to call the matching libusb_device_list_free() on the error path. This will
leak the memory allocated for the list as well as all the devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The victor-dmm driver uses libusb_get_device_list() but neglects to call
the matching libusb_device_list_free() on the error path of libusb_open().
This will leak the memory allocated for the list as well as all the
devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The testo driver uses libusb_get_device_list() but neglects to call the
matching libusb_device_list_free() on the error path. This will leak the
memory allocated for the list as well as all the devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
lascar_scan() calls libusb_get_device_list() but never the matching
libusb_free_device_list(). This will leak the memory allocated for the
device list as well as all the devices. To fix this add the missing
libusb_free_device_list().
While we are at it also make sure to handle errors returned by
libusb_get_device_list().
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some drivers check in some of their driver callbacks if the driver has been
initialized and return an error if it has not.
For the scan() callback the sigrok core checks if the driver has been
initialized and if not returns an error. So it is not possible that the
scan() callback gets called if the driver is not initialized. Without the
scan() callback succeeding it is not possible to get a reference to a
device which is associated with the driver, so it is not possible that any
of the device specific callbacks is called without the driver first being
initialized either.
In conclusion these checks are not necessary since they never evaluate to
true and can be dropped. If they should ever become necessary they should
be done in the sigrok core so all drivers and all callbacks are equally
handled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SR_CONF_CONTINUOUS is a capability option indicating whether a device
supports continuous capture or not. If the option exists the device
supports continuous capture and otherwise it doesn't. There is no value
associated with it and hence setting the SR_CONF_SET flag is nonsensical.
None of the drivers which set SR_CONF_SET for SR_CONF_CONTINUOUS handle it
in their config_set() callback and return an error if an application tried
to perform a config_set() operation for SR_CONF_CONTINUOUS.
Simply remove the SR_CONF_SET flag from all SR_CONF_CONTINUOUS options.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Every single hardware driver has the very same implementation of the
dev_list() callback. Put this into a helper function in the standard helper
library and use it throughout the drivers. This reduces boiler-plate code
by quite a bit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If a driver does not implement a dev_clear() callback the core will
automatically call std_dev_clear(di, NULL). Remove all driver dev_clear()
implementations that are identical to default. This reduces the amount of
boiler-plate code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
std_init() allocates a drv_context struct which needs to be freed by the
driver in its cleanup struct. But the vast majority of drivers does never
does this causing memory leaks.
Instead of addressing the issue by manually adding code to free the struct
to each driver introduce a new helper function std_cleanup() that takes
care of this. In addition to freeing the drv_context struct std_cleanup()
also invokes sr_dev_clear() which takes care of freeing all devices
attached to the driver.
Combining both operations in the same helper function allows to use
std_cleanup() as the cleanup callback for all existing drivers, which
reduces the amount of boiler-plate code quite a bit.
All drivers are updated to use the new helper function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the scpi-pps driver do have additional data attached to it that
needs to be freed when the device is freed. While the driver gets it right
for the cleanup() callback it does not for the dev_clear() callback. This
will cause memory leaks when sr_dev_clear() is called for this driver.
To fix this let the dev_clear() free the additional data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the deree-de5000 driver do have additional data attached to it
that needs to be freed when the device is freed. While the driver gets it
right for the cleanup() callback it does not implement a dev_clear()
callback, so the default dev_clear() implementation is used which will not
free the additional data. This will cause memory leaks when sr_dev_clear()
is called for this driver.
To fix this provide a dev_clear() implementation that frees the additional
data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the demo driver do have additional data attached to it that
needs to be freed when the device is freed. While the driver gets it right
for the cleanup() callback it does not implement a dev_clear() callback, so
the default dev_clear() implementation is used which will not free the
additional data. This will cause memory leaks when sr_dev_clear() is called
for this driver.
To fix this provide a dev_clear() implementation that frees the additional
data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When g_file_get_contents() encounters an error a new GError will be
allocated and passed back to the application. The application is
responsible for freeing this GError.
The baylibre-acme driver currently does not do this and as a result leaks
memory during the scan process when no device is found.
Add the missing g_error_free() invocations to fix the issue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure to free the FTDI device list and the FTDI context in scan_all()
otherwise memory leaks can be observed. Also make sure to free the FTDI
context in scan_device() on the error path.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This makes the code shorter, simpler and more consistent, and also
ensures that the (same) debug messages are always emitted and the
packet.payload field is consistently set to NULL always, etc.
The USBee AX hardware needs a sampling clock that is lower than
the 30MHz or 48MHz that the FX2 has to offer. This flag will enable
clocking via the CTL2 pin that is an even divisor of the main clock.
The driver did not look at the mq_flags provided with the
SR_CONF_MEASURED_QUANTITY key, and it defaulted to DC measurements.
Use the second member of the tuple provided by the config key, which
represents the flags for the measurement, and set the instrument's
measurement mode accordingly.