Acquisition won't work correctly in a multi-threaded environment, when
config_set() and config_get() are called with a channel group.
The channel switching itself has moved to scpi/scpi.c, to be able to
handle switching in a thread safe way.
Use of the thread safe SCPI functions, so no write+read operation is
interruped.
Also return float values instead of double value in acquisition mode.
This is related to bug #779.
This ensures that SCPI read/write/write+read operations are thread safe.
F.e.: If a write operation expects a return value (in other words: a
read operation), it is not allowed to be interrupted by another write
operation.
To simplify things, the SCPI helper functions are moved from
scpi/helpers.c to scpi/scpi.c and also are renamed to fit the naming
scheme.
libgpib in particular will abort the program execution in case of
concurrent operations.
The chronovu_la8 input module is capable of handling either file type,
generated by LA8 or LA16 vendor software. Automatic detection is not
available, but user provided channel counts work fine.
Adjust the input module's name and description, and claim support for
.kdt as well as .kd1 files.
Add developer notes on implementation details, the file content's
constraints, and potential future adjustment.
The file format is funny, a data part is leading (fixed size) and a
"header" part follows. The previous implementation sent the header part
to the session, too, pretending it was part of the data. This change
limits the number of samples that get sent to the session.
Comment on the file layout and header fields while we are here. This
information got lost in commit 02e24c0ce0 when the input module got
converted from do-it-yourself file operations to having intrinsic
handler routines invoked from common logic which handles the file.
Prefer the more portable UINT64_C() macro over the UL suffix when a
literal needs to span "more than 31 bit positions". Adjust other
locations for consistency across the source file.
Commit 8c4bff1d25 introduced a routine which prints what mostly should
be text, and avoids non-printable characters. This implementation used an
incorrect format string, which could result in data getting written past
the end of a buffer. Fix the format string.
src/hwdriver.c: In function ‘log_key’:
src/hwdriver.c:648:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
opstr = op == SR_CONF_GET ? "get" : op == SR_CONF_SET ? "set" : "list";
^~
src/hwdriver.c: In function ‘check_key’:
src/hwdriver.c:681:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
opstr = op == SR_CONF_GET ? "get" : op == SR_CONF_SET ? "set" : "list";
^~
src/hardware/siglent-sds/api.c:596:3: warning: Argument to g_free() is the address of a global variable, which is not memory allocated by malloc()
g_free(cmd);
^~~~~~~~~~~
src/hardware/siglent-sds/api.c:641:3: warning: Argument to g_free() is the address of a global variable, which is not memory allocated by malloc()
g_free(cmd);
^~~~~~~~~~~
Reported by scan-build:
src/hardware/lecroy-xstream/protocol.c:680:12: warning: Potential leak of memory pointed to by 'analog.data'
return SR_ERR;
^~~~~~
Reported by scan-build:
src/input/logicport.c:1186:18: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
.format_match = format_match,
^~~~~~~~~~~~
Log determined header format when parsing trace32 file headers. Keep
another log message during regular processing, but silence it during
format match.
Use more appropriate data types for local and instance variables. Adjust
format strings accordingly.
There were several issues with the previous implementation of the logic
which parses trace32 input files: A string comparison was inverted, and
compared a seven character literal to a five character copy of the input.
One more character was trimmed before CTRL-Z (the CP/M EOF), which often
is SPACE in input files, but might be excessive on other input files.
Replace a DIY character search while we are here. Use symbolic names for
special characters. Factor out a test and memory release, to simplify
error code paths in the remaining logic. Extend comments.
There is not much point in log messages about format mismatch in the
auto detect phase, where each module gets queried in turn and most are
supposed to not match.
Do not print non-printable characters in log messages. Those could occur
in the format detection phase, or in the regular processing of input
files that either are unexpected or invalid (or is there a binary header
format variant even?).
Although the file format handled by this input module appears to be of
fixed size (8MiB plus 5 more bytes), it's more reliable to use a data
type for the file size that is larger than "an int". Although off_t
would be most portable, use uint64_t to match the code which passes the
parameter to the input module.
The previous implementation already was inconsistent (used to allocate
255 bytes and claimed that 128 bytes were sufficient). While existing
formats already required more than a few bytes of input (regular VCD
files' header sections exceed 255 bytes length).
Increase the buffer size that gets passed to input modules' match
method. Use 4MiB for consistency with other locations. Do not enforce a
minimum size, as there are valid input files which are shorter than 128
bytes. Auto-detection failed on those.
This addresses part of bug #1200.
When users don't specify the input format, applications can try to have
the format auto-detected. Some of the tests were weak and could result
in false positives.
Add a 'confidence' parameter to the input modules' format_match()
method. Claim high confidence (1) for those formats which can check
magic strings or the presence of essential keywords (vcd, wav). Claim
medium confidence (10) for those formats which happened to mis-detect
inputs in the past (trace32_ad). Claim weak confidence (100) for those
formats which totally lack reliable conditions and rather guess than
detect (chronovu_la8).
Prefer the best match in public scan routines. Return at most one module
to callers even if multiple modules matched, to keep the current API.
This addresses part of bug #1200.
Implement an input module for .lpf files, the "LogicPort File" format of
the Intronix LA1034 vendor software. This version supports wires with
enabled and inverted state, compressed samples, signal names, signal
groups (but not multiple assignment), and automatic format detection.
The logic which determines whether "the file header" was completely
received, and sample data can get sent to the session, implements an
assumption in the absence of a better and more reliable condition.
Invalid input gets rejected, but diagnostics is rather limited. Since
all channels get to be the member of a channel group, either specified
by the user in the input file, or arranged for in the input module, the
"missing separator" part of bug 1186 has become obsolete.
src/analog.c:205:23: warning: declaration of ‘i’ shadows a previous local [-Wshadow]
for (unsigned int i = 0; i < count; i++) {
^
src/analog.c:178:18: note: shadowed declaration is here
unsigned int b, i, count;
^
[...]
src/analog.c: In function ‘sr_analog_to_float’:
src/analog.c:194:9: warning: declaration of ‘offset’ shadows a previous local [-Wshadow]
float offset = analog->encoding->offset.p / (float)analog->encoding->offset.q;
^~~~~~
src/analog.c:177:8: note: shadowed declaration is here
float offset;
^~~~~~
Allow developers to specify the (default) number of frames at compile
time (default to "off" as before). Accept the frame limit spec at scan()
time as well. This is useful when applications don't run config_set() at
runtime.
Tested with:
$ pulseview -d demo:logic_channels=0:analog_channels=1:limit_frames=4
The previous implementation supported the generation of frames as a
compile time option. This change lets users adjust the feature at
runtime.
In the absence of a frame count limit no frame begin/end markers get
sent (the default behaviour of the previous implementation). When a
frame count limit is specified, the respective number of frames gets
sent and acquisition stops.
The fixed amount of 1000 samples per frame is an arbitrary choice. This
compile time option is easily adjusted in the source code.
Introduce support for the "graycode" logic pattern. Generate up to
64 bits of graycode output (all logic lines, no repetition, not limited
by the generator's internal pattern buffer). The implementation was
tested with 16 channels.
Keep a context variable around with a bit mask for all logic channels.
This is convenient in setup and generation routines, to avoid garbage
in unassigned bit positions of session feed packets.
Move the declaration of codes for pattern types before the declaration
of the context container such that the latter can reference the former.
Add 'int' to an unsigned variable that omitted the base type.
When auto-detection tries to find the input module that can handle a
file, unexpected input format should be considered non-fatal. Only emit
error messages when process_header() got invoked from process_buffer()
after initialization. Emit debug messages in early stages where no input
module context exists yet.
The initial voltage threshold in dev_open() was being set to a
default value in the devc->cur_threshold variable but not actually set
in the device itself.
Patch by Jörg Alpers <jalpers@gmx.net>, thanks a lot!
- fix LIBUSB_TIMEOUT errors
- fix same data receiving
- send reset vendor request before new data getting
- decrease USB polling timeout
This fixes bug #1190.
Signed-off-by: Andrej Valek <andy@skyrain.eu>
- use pragma to handle different behavior between gcc and minGW bit-field packing
- bit-field integer variables needs to be align to 2-byte boundary
Compiler does not produce an error when accessing into non-__packed pointer.
However, the field might not be properly aligned for this type.
More information could be found on:
- https://sourceforge.net/p/mingw-w64/bugs/275/
- http://www.keil.com/support/man/docs/ARMCC/armcc_chr1359124990875.htm
Signed-off-by: Andrej Valek <andy@skyrain.eu>
Before this change, the loglevel check would only be performed for the
default log handler in libsigrok, but not for other handlers set
via sr_log_callback_set().
This fixes bug #698.
A local buffer was too small, snprintf() was used to write the
name of the analog-1-1-xxx ZIP archive names in that buffer.
Due to the limited size, only 3 characters were usable for the last
number component, i.e. the code would loop around from analog-1-1-999
to analog-1-1-100 (instead of analog-1-1-1000).
As a quickfix, increase the buffer size by a large margin, a nicer
fix should be used later on.
These trigger quite often with unrelated devices and confuse people.
scpi_usbtmc: Failed to get configuration descriptor: LIBUSB_ERROR_NOT_FOUND, ignoring device.
The Modbus RTU implementation was inappropriately returning lengths
from the serial functions when the calling functions expect only an
sr_error_code value.
Make sure to not exceed the ctx->analog_samples[] array bounds. Don't
use the (huge) channel's index in the device's(!) channel list, instead
use the zero-based and dense index into the array of analog samples in
the accumulation buffer, before writing to the external file.
This fixes the segfault reported in bug #1124.
The process_analog() logic is rather complex, dealing with the total
list of channels in the device (which can be of different types), and a
number of submitted samples for a specified list of channels. Replace
the rather short variable names for i, j, c (and num_channels) with
something longer that hopefully increases readability of the complex
loop bodies.
Note that this change merely renames identifiers, and does not change
behaviour.
Instead of nesting indentation levels upon equality of a value, skip
iterations upon inequality. This reduces indentation, and might improve
readability.
[ Indentation changes, see 'diff -w -b' for the essence. ]
Use serial_readline in acquisition mode, otherwise data from the
Re:load Pro could get lost.
Use reloadpro_receive_data() for all commands when in acquisition
mode. When not using a single point of receiving data, data could get
lost.
Prefer sigrok's endianess conversion helper over the inet htons()
routine which is harder to read (is "network order" little or big?).
Writing the conversion results in units of bytes also avoids misaligned
memory access. The header length is odd, each payload item got written
as an uint16_t item to an odd address.
The config.h file must always be included as first file.
src/output/csv.c: In function 'gen_header':
src/output/csv.c:64:20: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "output/csv"
^
./src/libsigrok-internal.h:753:42: note: in expansion of macro 'LOG_PREFIX'
#define sr_info(...) sr_log(SR_LOG_INFO, LOG_PREFIX ": " __VA_ARGS__)
^
src/output/csv.c:244:3: note: in expansion of macro 'sr_info'
sr_info("Set sample period to %" PRIu64 " %s",
^
src/output/csv.c: In function 'dump_saved_values':
src/output/csv.c:462:34: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
g_string_append_printf(*out, "%" PRIu64 "%s",
^
In file included from src/hardware/ftdi-la/protocol.c:21:0:
src/hardware/ftdi-la/protocol.c: In function 'send_samples':
src/hardware/ftdi-la/protocol.h:28:20: warning: format '%u' expects argument of type 'unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "ftdi-la"
^
./src/libsigrok-internal.h:751:42: note: in expansion of macro 'LOG_PREFIX'
#define sr_spew(...) sr_log(SR_LOG_SPEW, LOG_PREFIX ": " __VA_ARGS__)
^
src/hardware/ftdi-la/protocol.c:29:2: note: in expansion of macro 'sr_spew'
sr_spew("Sending %" PRIu64 " samples.", samples_to_send);
^
Optionally create multiple analog channels in serial-dmm's scan()
routine. Allow the meters' parse routines to fill in more than one
analog value from the inspection of a single packet.
Use "large" (4 times 14 bytes) packets for the Metex M-3860M and the
PeakTech 4390A meters, and have those large packets parsed by wrapping
the routines for regular 14-byte Metex packets, and sending four values
to the session bus after reception of one large packet.
Thanks to Frank Stettner <frank-stettner@gmx.net> for testing and
fixing the initial implementation of this extension.
Move the initial assignment to the 'offset' variable to the very spot
where it gets evaluated and subsequently manipulated.
Replace a DIY copy loop with the corresponding memmove(3) call.
Also use "r" and "f" as trigger slope values for now, since that's
what most other drivers do currently.
This also fixes two scan-build issues:
api.c:559:3: warning: Value stored to 'tmp_str' is never read
tmp_str = g_variant_get_string(data, NULL);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
api.c:561:9: warning: Use of memory after it is freed
ret = siglent_sds_config_set(sdi, "%s:TRSL %s",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The strcasestr() function is non-portable (e.g. not available on
MinGW, possibly elsewhere). Replace it with g_strstr_len() for the time
being. While the latter is not case-insensitive it appears that
that property doesn't matter here ("." should not be relevant anyway,
and e.g. an SDS1202X-E does indeed report "Mpts" as such).
Should it become necessary to have this code be case-insensitive,
we'll have to find a more portable solution than strcasestr().
This causes some compile errors on platforms where RPC is not available, e.g.
siglent-sds/api.c:25:21: fatal error: rpc/rpc.h: No such file or directory
Surrounding the #include (and later code) with "#if HAVE_RPC" should avoid
these compile errors, but since it's not used at all for now, drop it.
Make the USB reset for USB TMC devices conditional. Check a whitelist,
which in this implementation exclusively contains the Siglent VID.
The whitelist's comment may need adjustment. The VID probably not only
applies to SDS devices, but could be used for SDG and others as well.
And lsusb output suggests the VID is used by Atten, too.
Add the Siglent's VID to a list of blacklisted USB TMC devices.
Unconditionally reset USB devices in the open routine.
This was taken from marchel's development for Siglent SDS. Though the
reset should probably be conditional, and only get applied to devices
which are known to need it.
The comment may need adjustment, maybe individual PID entries are
required. The VID probably not only applies to SDS devices, but could
be used for SDG and other gear as well. And lsusb output suggests the
VID is used by Atten, too.
Implement a first version of the driver for the Siglent SDS1000 and
SDS2000 oscilloscopes.
[ gsi: This commit corresponds to git 0228126017e6 of marchelh's tree,
I adjusted the source to closer match the project's coding style. The
conversion was verified by this command:
$ git diff --word-diff=color -w -b <branch>:<dir> <branch>:<dir>
Changes include: Whitespace adjustment, dead code removal, separation
of variable declaration and assignment, alpha-sorted includes. Line
length was not addressed and not every location got adjusted, to keep
the diff minimal and to reduce effort during review of this version. ]
Check for successful allocation before accessing struct members. Return
with an error from device initialization when allocation fails.
This was reported by clang's scan-build.
Make sure to release the allocated "pod enabled" memory, too, when SCPI
communication during channel setup fails. Defer the return with an error
(instead of duplicating the free() invocation).
This was reported by clang's scan-build.
The compiler marks a potential use after free, which the current
implementation won't trigger. The error only occurs when a sigrok
channel is neither logic nor analog.
Address the issue nevertheless, to silence the compiler warning, and to
protect against possible programming errors when a future implementation
should support more channel types.
This was reported by clang's scan-build.
Fixup unbalanced braces for more complex if statements, to better
reflect the project's official coding style.
Adjust data types in the float_to_le() routine. A float value gets
copied to a buffer of bytes (uint8_t). Don't use 'char' on the other
side of assignments, to not assume a specific width for char, and to
avoid potential signedness issues. Copy from bytes to bytes instead.
The WAV output module supports an optional 'scale' factor, in its
absence the samples will pass unmodified. The builtin help text is
unexpected, and reads:
$ sigrok-cli -O wav --show
...
Options:
scale: Scale values by factor (default 0.0)
Setup a default scale factor of 1.0, which results in identical
behaviour and better reflects what is happening.
The previous implementation only emitted data for the first enabled
channels, and "saw no changes" after emission of the initial value for
channels on positions that followed a disabled channel.
Assume that the received data from the session bus communicates the bits
of enabled channels in a packed representation. Skip the mapping of
output bit indices to sigrok channel numbers.
This fixes the remaining part of bug #519.
Tested by inspecting in gtkwave the result of command:
$ sigrok-cli -d demo -C D1,D3,D6 -c samplerate=2M --samples 2500 -O vcd -o trace.vcd
When we find that all input sources (device drivers, and input modules)
provide a dense bit field, all of the mapping logic can get removed
here. This commit just quickly disables the logic.
Identifiers for channels in the VCD header section could be "sparse"
when sigrok channels were disabled. Make sure to not assign names to
disabled channels. This will e.g. assign !, ", and # to channels D1, D3,
and D6, when D0, D2, D4-D5, and D7 are disabled.
This addresses part of bug #519.
Few DMM drivers already did it. This commit adjusts the remaining DMM
drivers, to set the "DC" flag for measurements in diode mode.
This fixes bug #144.
Although I don't have the hardware to test, the nature of the change and
the arrangement of driver code suggests it's good. When a meter already
communicated the "DC" status, the change does nothing and won't harm.
The change ensures "DC" is flagged for those meters which previously
didn't, which is desirable.
Some SCPI based drivers fail to convert response data, because strutil
conversion helpers sr_atol() and sr_atof() don't like trailing spaces
after the number's text that successfully got converted.
It's yet to get determined whether all call sites of the conversion
routines like their eating adjacent whitespace. But given that the
conversion routine explicitly checks for end of the string after the
number, no call site should expect or even depend on trailing text to
keep its whitespace.
See bug #788 for a discussion and example data.
Synchronize sr_parse_sizestring() with sr_si_string_u64() capabilities.
Add support for the T/P/E suffixes. Since this conversion helper deals
with integer values exclusively, there is no issue with case insensitive
matches. The value cannot be pico. Neither is there an ambiguity with
the 10e6 notation.
This addresses bug #763.
Fix a style nit while we are here. Put braces around both arms of a
complex conditional.
Explicitly assign NULL to param to avoid the "may be used uninitialized"
warning reported in bug #1094. Behaviour remains unchanged. All references
to the variable were under "if (!conn)", and the assigning arm of the
branch checked for "if (!param)" after assignment. So the error could
not happen, but compilers may not have noticed depending on the width of
their scope during compilation.
Move the initialization of 'conn' closer to the conditional assignment,
such that all paths are seen in one spot during maintenance.
This fixes bug #1094.
Although log messages are terminated by a line feed, output still might
get buffered when the program does not talk to a terminal (that it is
aware of). Add an fflush(3) call to the printf(3) sequence such that log
output will immediately show up when writing to pipes or sockets, too.
Early sr_init() steps can just 'return' fine. After allocation of the
'context' memory, make all error paths 'goto done' before returning,
to undo the memory allocation.
The srzip output module dropped support for the "filename" option in
commit 37875f7506 on 2015-07-30, but still used to assign to slot
options[0] which clobbers the array's sentinel. Remove those accesses
to the non-existing option.
api.c: In function 'config_set':
api.c:352:5: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'uint64_t' [-Wformat=]
sr_err("invalid sample range 2k...64M: %ld",
^
beaglelogic_tcp.c: In function 'beaglelogic_tcp_send_cmd':
beaglelogic_tcp.c:114:3: warning: format '%lu' expects argument of type 'long unsigned int', but argument 4 has type 'size_t' [-Wformat=]
sr_dbg("Only sent %d/%lu bytes of command: '%s'.", out,
^
Check pointers' validity before dereferencing them. Release partially
allocated memory in an error path. Remove an assignment which never took
effect.
This was reported by clang's scan-build.
Each code path either assigns to 'flags', or leaves the routine. There
is no potential path that leaves the variable at the initially assigned
value, so the assignment took no effect. Remove it.
Nit: Trim the source code line length while we are here.
This was reported by clang's scan-build.
Check pointers' validity before dereferencing them. Explicitly assign a
default value to variables, before conversion routines conditionally
assign the "real" value (and don't in case of conversion errors). This
avoids processing "garbage" data.
Strictly speaking I cannot see how the conversion routine returns OK and
has _not_ assigned a result. But the explicit assignment won't harm
either, and matches the fallback when the conversion fails (detectibly).
Which means that runtime behaviour won't change.
This was reported by clang's scan-build.
Remove an assignment that won't take effect. Check pointers' validity
before dereferencing. Fix a memory leak.
This was reported by clang's scan-build.
Check for successful allocation of multiple memory ranges, and release
partial allocations in the error path when one of them failed. This
fixes a potential memory leak, as well as avoids NULL dereferences.
This was reported by clang's scan-build.
Silence warnings about assigned values that never get used, potential
NULL deference, and potential memory leaks.
This was reported by clang's scan-build.
The scan_2x_bd232() routine used to always prepare one spare context,
and filled it in when a device was found, just to allocate another one
and continue scanning.
Free the last allocated context unconditionally, as it was allocated
unconditionally, and never used.
This was reported by clang's scan-build.
Stick with the prepared but unfinished "limit msec" code path, but
silence the warning about an unused variable value.
This was reported by clang's scan-build.
Avoid a division by zero, by not using a zero unitsize in a modulo
operation. As a byproduct, avoid processing and counting input that
neither has analog nor logic data. This should never have happened,
but the change now catches the error if invalid input is seen.
This was reported by clang's scan-build.
The sr_packet_copy() routine could have written to an arbitrary memory
location. Make sure to allocate the space before writing to it, and
check for successful allocation before accessing the memory.
It's assumed that this error never took effect, as the routine appears
to be unused.
This was reported by clang's scan-build.
The 'opc' variable was only conditionally assigned to (depends on
successful SCPI communication). Ensure there always is a known value.
This was reported by clang's scan-build.
After the first capture ->num_frames never got to be _equal_
to ->limit_frames; fixed by resetting to zero in dev_acquisition_stop(),
and protected against similar problems in the future by switching to
greater-or-equal instead.
[Note: This patch is basically a squashed version of the initial driver
commits by Andreas Zschunke <andreas.zschunke@gmx.net>, two fixes by
Andrej Valek <andy@skyrain.eu>, and various coding style / cosmetic
fixes by Uwe Hermann <uwe@hermann-uwe.de> to make the driver a lot more
consistent with the rest of the libsigrok code-base.]
When refactoring the code, some places where sr_scpi_send was replaced
by rigol_ds_config_set the first argument was not changed from sdi->conn
to sdi. Fix the remaining ones.
Fix: https://sigrok.org/bug/1073
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
This regression was introduced in f1ba6b4b2c.
Due to how the sysclk-lwla driver does up to 3 open/close operations in
one dev_open() API callback we cannot rely on the sr_dev_open() and
sr_dev_close() wrappers setting the sdi->status variable in this case.
Tested on LWLA1034.
When processing of large VCD input files was spread across multiple
parse_contents() invocations, the resulting sigrok stream of sample data
had gaps in them and total timing was off. For instance 74ms of input
data were interpreted as spanning some 600ms or 300ms, depending on the
number of channels in the input stream.
Move the "previous timestamp" variable to the input module context. This
eliminates the inappropriate gaps and fixes the translation of VCD file
timestamps to sigrok sample numbers.
This fixes bug #1075.
Some drivers used locale dependent functions for converting strings
to float/double values. These functions fail when the decimal mark
is a "," in the locale settings but the string contains a ".".
This fixes bug #1064.
A "low samplerate" in this case means anything where
samples_todo is less than SAMPLES_PER_FRAME. This case
wasn't handled properly before, resulting in wrong
amounts of data being sent out.
We can't use the memory size command because it returns
the *maximum* memory used, not the *actual* memory used.
Hence, we only know the number of samples per div once
sample data actually comes in.
As there is a huge range of supported LeCroy scopes, naming
the IDN response for every single one of them is going to be
impossible. Hence, it makes more sense to treat all LeCroy
devices as if they were scopes and supported. This approach
lets users try to see how far they get and if they run into
issues, they can then be treated separately - e.g. by creating
a custom device profile.
Unless we do this, the vast majority of LeCroy scopes will
not be recognized by the driver.
Set samplelimit to a sane value (was causing PulseView to
crash earlier), as well as advertise samplerate using SR_CONF_LIST
so that PulseView can show the sample rates.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
The function drains off all the remaining data in the receive socket
and is triggered before starting a capture and after a capture is
completed. In the absence of this function, there is a possibility of
data corruption and also the NodeJS TCP server throws an error if the
buffer is not completely read out before the socket is closed.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
BeagleLogic now supports two modes of interface - one being the
native mode running on an ARM system like the BeagleBone Black
and the other mode acting like a TCP client for the BeagleLogic
server running off a BeagleBone compatible system. This makes it
convenient for desktop users to retrieve samples from BeagleLogic,
no more copying files and SSHing into the BeagleBone hardware in
order to use BeagleLogic.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Organize driver functions into an ops structure (there will be
separate structures for both native and TCP mode of operation).
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
The code earlier was in a single .h file, so it's now separated into a C file
and H file
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
If a channel in the higher-than-8-bit group is enabled then use
16-bit captures. Otherwise just do 8-bit captures.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Starting with Linux kernel version 4.9, BeagleLogic attributes
setting does not require root permissions.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
This is unlike the previous behavior to return 8 channels and then
use logic_channels to get all the 14 channels
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Values like '-0.1' would be parsed as being positive, as the integral
type does not discern +0 and -0. Also allow values without leading
integral value, to match behaviour of strtod/sr_atof.
This was leading to an invalid threshold config value and indirectly
to frontend issues.
Slightly modified patch from James Churchill <pelrun@gmail.com>, thanks!
The previous implementation unconditionally submitted analog data
whenever values could get extracted out of received serial packets.
This commit checks the channels' enabled state before submission. Care
is taken to obey the user's acquisition limits, exclusively counting
submitted not received values.
Upon reception of serial data from the ES51919 LCR chipset, the data for
channels P1 and P2 was extracted from the packet, and unconditionally got
sent to the sigrok session.
Do check the channels' enabled state before submission. This fixes for
serial-lcr what recently got reported for a Brymen DMM. Tested with
$ sigrok-cli -d peaktech-2170:conn=/dev/ttyUSB0 --channels P2
and other --channels specifications.
The es51919_serial_clean() routine is called by std_dev_clear_with_callback().
Common code unconditionally frees the 'priv' part. The cleanup callback only
shall release descending resources which are local to the callee and opaque
to the caller.
This fixes a double free error. Tested with PeakTech 2170.
$ sigrok-cli -d peaktech-2170:conn=/dev/ttyUSB0 --show
When the acquisition was stopped before a configured limit was reached,
no sample data was retrieved. This is because the api.c stop routine did
unregister the receive callback.
Pass the stop request to the receive routine instead when stop is called
while the acquisition is still running. Have sample data downloaded very
much like it's done for reached limits, and existing logic will run the
stop routine again after state was advanced to "idle".
Extend the 'state' tracking while we are here, mark sample download as
well (that was omitted in the previous implementation). Though the
omission was non-fatal. Move the release of 'dram_line' to some earlier
location (as soon as the resource is not needed any longer), before some
rather complex calls to other routines will execute.
Reported-By: Michael Kaplan <M.KAPLAN@evva.com>
Move the check for the capture ratio being 0..100 into the wrappers,
drop unneeded helper functions, fix incorrect variable types, minor
other consistency fixes.
This makes the code more consistent with the rest of the code-base
and also allows std_gvar_min_max_step_array() to work here.
Without this change:
src/hardware/scpi-pps/api.c: In function ‘config_list’:
src/hardware/scpi-pps/api.c:570:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->voltage);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:573:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->frequency);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:576:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->current);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
This ensures consistent handling of the SR_CONF_SCAN_OPTIONS and
SR_CONF_DEVICE_OPTIONS (with sdi NULL or non-NULL) config keys
and also reduces copy-pasted boilerplate in the drivers a bit.
This function does not handle channel-group specific items, that's
very driver-specific and thus left to the individual drivers.
Also move some generic checks and error messages from the drivers into
the sr_config_list() wrapper.
The HW simply stops sending data on overflows, so if we receive no data
in one second, we abort the acquisition. We also need to allocate more
buffers to support higher sample rates.
Until now, clear_helper() callbacks for std_dev_clear_with_callback()
were expected to g_free(devc), but not all of them did that.
Have std_dev_clear_with_callback() unconditionally g_free(sdi->priv)
(i.e., devc), regardless of whether a clear_helper() callback was
provided or not. It was doing g_free(sdi->priv) when no callback
was provided already anyway.
This makes the individual drivers' clear_helper() implementations
shorter and prevents errors such as missing g_free(devc) calls.
This works, because all drivers either call std_dev_clear_with_callback()
directly, or indirectly via std_dev_clear().
This also allows us to remove some no-longer needed dev_clear()
and clear_helper() implementations that only did g_free(devc)
in favor of std_dev_clear().
Be explicit and consistent in the drivers about which dev_clear function
will be called to avoid confusion and inconsistencies.
Drop some open-coded implementations of std_dev_clear().
Drop unneeded log messages, add some others that might be useful,
document which ones we're intentionally not emitting.
Don't log "$operation successful" type of messages in most cases,
that's too verbose; logging failures only is sufficient there.
baylibre-acme: Don't log "No such file or directory" messages during scan,
this triggers on all kinds of unrelated devices (e.g. "AMDGPU i2c bit
bus 0x91" in this case):
sr: [...] baylibre-acme: Name for probe 1 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0040/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 2 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0041/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 3 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0044/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 4 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0045/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 5 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0042/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 5 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-004c/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 6 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0043/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 6 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0049/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 7 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0046/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 7 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-004f/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 8 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-0047/name”: No such file or directory
sr: [...] baylibre-acme: Name for probe 8 can't be read: Failed to open file “/sys/class/i2c-adapter/i2c-1/1-004b/name”: No such file or directory
- sr_dev_clear(): Don't try to clear uninitialized drivers (the same
check was previously done in std_dev_clear()).
- Document some places where we intentionally don't emit log messages.
- std: Various Doxygen fixes and updates.
- std: Add some more sanity-checks on input parameters.
src/hardware/saleae-logic-pro/protocol.c:389:12: warning: 'set_led' defined but not used [-Wunused-function]
static int set_led(const struct sr_dev_inst *sdi, uint8_t r, uint8_t g, uint8_t b)
^
CC src/hardware/saleae-logic-pro/api.lo
src/hardware/saleae-logic-pro/api.c: In function 'dev_acquisition_handle':
src/hardware/saleae-logic-pro/api.c:332:9: warning: missing initializer for field 'tv_sec' of 'struct timeval' [-Wmissing-field-initializers]
struct timeval tv = {};
^
In file included from /usr/include/x86_64-linux-gnu/sys/time.h:27:0,
from include/libsigrok/libsigrok.h:24,
from src/hardware/saleae-logic-pro/protocol.h:25,
from src/hardware/saleae-logic-pro/api.c:23:
/usr/include/x86_64-linux-gnu/bits/time.h:32:14: note: 'tv_sec' declared here
__time_t tv_sec; /* Seconds. */
^
The asix-sigma driver was reported to fail in combination with newer
libftdi versions, because the firmware upload routine opened again an
already opened device, and then failed to claim the interface. Which was
not fatal before with previous libftdi versions.
Remove the redundant open call. Remove the local FTDI context variable,
which brings the firmware upload routine in line with all other calls
that communicate to the USB device.
This fixes bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
The asix-sigma driver supports different samplerates, which will involve
different firmware images and will affect the number of available logic
channels as well as their memory layout in downloaded sample data.
Make sure to only store the configuration's parameters after the setup
of that configuration has successfully completed, and make sure to store
a consistent set of parameters. Specifically don't change the number of
channels when the firmware upload failed.
This fixes part of bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
The firmware upload code paths in the asix-sigma driver used to return
either the SR_OK code, or the magic number 0 for error conditions. Which
happens to be identical and cannot be told apart by callers.
Provide proper SR_ERR return codes for error conditions, such that
callers can tell whether the firmware upload succeeded.
This fixes part of bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
Adjust the string to boolean conversion for an edge case. Accept empty
text (either NULL or empty strings) to mean true instead of false.
This behaviour is more useful from the user's point of view, when the
option's name alone will enable a feature, and an explicit "option=yes"
specification is not strictly necessary. All calling applications in
mainline already implemented this semantics.
../src/hardware/hung-chang-dso-2100/api.c: In function ‘config_commit’:
../src/hardware/hung-chang-dso-2100/api.c:562:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
state = 0x01;
~~~~~~^~~~~~
../src/hardware/hung-chang-dso-2100/api.c:563:2: note: here
default:
^~~~~~~
../src/hardware/hung-chang-dso-2100/api.c:565:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (ret != SR_OK)
^
../src/hardware/hung-chang-dso-2100/api.c:567:2: note: here
case 0x01:
^~~~
../src/output/csv.c: In function ‘receive’:
../src/output/csv.c:580:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
*out = g_string_new(ctx->frame);
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
../src/output/csv.c:582:2: note: here
case SR_DF_END:
^~~~
../src/input/wav.c: In function ‘send_chunk’:
../src/input/wav.c:200:2: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
memset(fdata, 0, CHUNK_SIZE);
^~~~~~
../src/input/raw_analog.c: In function ‘init’:
../src/input/raw_analog.c:133:31: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Wformat-truncation=]
snprintf(channelname, 8, "CH%d", i + 1);
^~
../src/input/raw_analog.c:133:28: note: directive argument in the range [1, 2147483647]
snprintf(channelname, 8, "CH%d", i + 1);
^~~~~~
../src/input/raw_analog.c:133:3: note: ‘snprintf’ output between 4 and 13 bytes into a destination of size 8
snprintf(channelname, 8, "CH%d", i + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The previous implementation used to provide datafeed packets which
contain logic data in positions that correspond to disabled channels.
Do mask out logic data of disabled channels in the memory image before
it is sent to the session's datafeed. This implementation works fine for
those situations where either all logic channels are enabled (default
configuration) or when only the upper channels get disabled (which can
be considered a typical use case).
For those configurations where enabled channels follow disabled channels
(i.e. setups with gaps in the sequence of enabled channels) behaviour
will be unexpected: Neither is the mask adjusted to contain gaps, nor
will enabled channels get mapped to result in a dense representation.
The respective code paths are marked with TODO comments.
Add a comment to discuss a non-obvious generator call for analog data in
the acquisition start routine, while we are here.
The generator logic determines how many samples per group (analog and
logic) need to get produced, then keeps iterating until each group has
reached the specified count. Different groups can generate different
numbers of samples per iteration, they have their own stride.
It's essential to check whether all channels in a group are disabled, to
then completely skip the respective half of the generation loop. Without
this check, the group would be expected to generate data but it won't,
which results in an endless loop. This was observed with analog channels.
There was another issue with logic channels. Unexpected logic data was
seen in the output although neither logic channel was selected.
This commit fixes bug #923.
Skip the emission of session datafeed packets for disabled analog
channels.
Implementation detail: Allow for quick lookup of the channel that is
associated with an analog generator, as the data generation routines
only pass generator references in later calls.
This fixes part of bug #923 (which initially is about unexpected
logic data while analog channels were affected in similar ways).
After the requested number of samples was sent, another session df
packet was emitted with one sample for the analog channels, which
contained the most recent result of averaging. Make this emission
depend on the "averaging requested?" flag.
This fixes bug #930.
The 'demo' driver supports scan options to adjust the number of
supported channels, and runtime control for the enabled state of
channels.
Starting with zero analog channels created (scan option) resulted in a
runtime assertion. Creating but disabling analog channels (GUI checkbox,
CLI option) resulted in unexpected output for disabled channels.
Move the creation of a hash table out of the conditional loop that
iterates over created analog channels. Which results in the table's
always being valid, and iteration during data acquisition yields no
analog output as is expected.
This fixes bug #625.
A previous implementation of the demo driver supported the creation of
larger channel counts yet only enabling part of them by default. This
was kind of pointless, I just was not aware of the available scan
options.
Drop the "enabled channels" limitation, enable all channels that get
created (like the implementation before the experiment did), and create
as many channels as was compiled in by default or later got specified
by scan options.
Uwe Hermann
Sergey Alirzaev
Frank Stettner
Gerhard Sittig
Mandl
Andrej Valek
Sven Bursch-Osewold
James Churchill
Soeren Apel
Axel Hinrichs
marchelh
Romain Tartière
Philipp Marek
Andreas Zschunke
Michał Janiszewski
Stefan Brüns
Holger Müller
Timo Rothenpieler
Sylvain Pelissier
Joel Holdsworth
Kumar Abhishek
Marcus Comstedt
turboaffe
Jan Luebbe
Richard