Address minor style issues: Need not assign NULL after g_malloc0(), need
not check for NULL before g_free(). Rephrase diagnostics messages which
are user visible by default, remove internal development details. Reword
a few comments, and adjust their grammar for consistency across the code
base. The sr_analog_init() routine executed immediately before getting
measurements, need not (re-)assign endianess or floating point details,
except those which do change after initialization (double vs float).
Rephrase model dependent checks for easier adjustment during maintenance.
Unobfuscate string comparisons.
Manufacturer revised hardware design without changing model numbers at some point.
Old units have firmware that behaves differently. Responses are terminated with \r
instead of \n. And STATUS? command response format is different.
Quite some drivers flush the serial port after opening it. And quite
some don't although they should. Factor this out, so serial_open() will
always flush the port. The removal in the drivers was done with this
small coccinelle script:
@@
struct sr_serial_dev_inst *serial;
@@
serial_open(serial, ...)
... when != serial
- serial_flush(serial);
and then the results and the unmatched findings of serial_flush() were
audited.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
When using a number of frames that is not 1, the driver will read
samples up to its limit and then wait for another trigger. This will be
repeated until the configured number of frames has been finished.
According to the programming manual, one should issue
:WAV:RES
:WAV:BEG
before reading data from internal memory. Without this, the wrong data
will be returned.
- always say 'ID' when the ID command failed
- print hexdump of a faulty ID because on a stalled device we may get
0x00 bytes which would terminate the string early.
Signed-off-by: Wolfram Sang <wsa@kernel.org>
This changeset adds support for the RDTech TC66C USB power meter.
Currently, the driver reports the following channels:
* V: VBus voltage
* I: VBus current
* D+: D+ voltage
* D-: D- voltage
* E: Energy consumed in threshold-based recording mode.
The number of significant digits shown for each channel has been set
to match the number of digits shown on the device.
Usage example:
sigrok-cli -d rdtech-tc:conn=/dev/ttyACM0 --scan
Known issues:
* BLE support is currently unimplemented. This uses a different
command set, but the same poll data format.
Kudos to Ben V. Brown for reverse engineering some of the protocol and
documenting the encryption key used for poll data.
Signed-off-by: Andreas Sandberg <andreas@sandberg.pp.se>
This changeset adds support for the RDTech UMxx series of USB power
meters. The driver has been tested with the RDTech UM24C, but should
support the UM24C, UM25C, and the UM34C.
Currently, the driver reports the following channels:
* V: VBus voltage
* I: VBus current
* D+: D+ voltage
* D-: D- voltage
* T: Device temperature
* E: Energy consumed in threshold-based recording mode.
The number of significant digits shown for each channel has been set
to match the number of digits shown on a UM24C.
Missing features:
* There is currently no support for configuring threshold-based
recording from sigrok, but this can be done on the device itself.
* Fast charging mode currently not logged.
Usage example:
sigrok-cli -d rdtech-um:conn=bt/rfcomm/MAC --scan
sigrok-cli -d rdtech-um:conn=/dev/rfcomm0 --scan
Known issues:
* When using sigrok's Bluetooth transport implementation, the device
is disconnected between probing and sampling. Some devices (e.g.,
the UM24C), dislikes this and can't be reconnected reliably for
sampling. This is not an issue when setting up a rfcomm device
manually and using it as a serial port.
Kudos to Sven Slootweg for documenting most of the protocol.
Signed-off-by: Andreas Sandberg <andreas@sandberg.pp.se>
The meter allows remote controlled start of recordings, but requires a
few parameters where it's uncertain how to most appropriately get these
by means of SR_CONF_* keys.
Introduce SR_CONF_SET support for SR_CONF_DATALOG to raise awareness,
but leave the implementation empty for now. Leave a TODO comment which
discusses the meter's commands that one might want to use from here.
Extend the previously introduced skeleton driver for UNI-T UT181A. Introduce
support for the full multimeter's protocol as it was documented by the ut181a
project. Which covers the retrieval of live readings, saved measurements, and
recordings, in all of the meter's modes and including relative, min/max, and
peak submodes. This implementation also parses compare mode (limits check)
responses, although it cannot express the result in terms of the session feed.
Announce the device as a multimeter as well as a thermometer, it supports
up to two probes including difference mode. When in doubt, prefer usability
over feature coverage (the driver side reflects all properties of the meter,
but not all features can get controlled by the driver). The probe routine
requires that users specify the serial port, and enable serial communication
on the meter.
Several TODO items remain. Comments in the driver code discuss limitations
of the current implementation, as well as cases where the meter's features
don't map well to sigrok's internal presentation. This implementation also
contains (optional, off by default) diagnostics for research on the serial
protocol.
When data patterns for trigger specs span multiple bits, users may not
want to specify long lists of "<ch>=<lvl>" conditions for sigrok-cli's
--trigger option, and count channels by hand. Or click a dozen dialogs
to specify one data pattern, or modify a previous specification. Setups
with few traces may accept that, "data heavy" setups like parallel data
or address bus inspection may not.
Add comments which discuss the potential use of SR_CONF_TRIGGER_PATTERN.
Outline a syntax which may be flexible enough _and_ acceptable to users,
support data patterns and edge triggers alike, in several presentations
that serve different use cases. This commit exclusively adds comments,
does not change behaviour.
Update a comment in the user spec to internal format trigger spec parser
to expand on hardware constraints and implementation limitations. Rename
an identifier which checks the number of edge conditions, not the number
of accepted trigger spec details.
Trigger support became operational again. Drop the compile time switch
which disabled the previously incomplete implementation.
This resolves bug #359.
Parse trigger specs early when acquisition starts, timeout calculation
needs to reflect on it. Either immediately start an acquisition timeout
for trigger-less configurations. Or prepare a timeout which spans the
post-trigger period, but only start its active period when the trigger
match was detected by the device's hardware.
Extend mode tracking during acquisition to handle other special cases.
Terminate acquisition when the user specified sample count limit exceeds
the hardware capacity, or when no limits were specified and the device's
memory is exhausted.
There is a slight inaccuracy in this approach, but the implementation
fails on the safe side. When both user specified limits and triggers are
involved, then at least the user specified time or sample count span is
provided. Usually more data is sent to the session feed, and all of the
requested period is covered. This is because of the software poll period
and the potential to start the timeout slightly late. As well as having
added some slack for hardware pipelines in the timeout calculation.
The previous implementation ran the complete sample memory retrieval
in a single call to the receive callback. Which in combination with
slow USB communication and deep memory could block application logic
for rather long periods of time.
Rephrase the download_capture() routine such that it can spread its
workload across multiple invocations. Run the acquisition stop and
resource allocation for the download, the interpretation of a set of
DRAM lines, and the resource cleanup, as needed. And keep calling the
download routine until completion of the interpretation of the sample
memory region of interest. The workload size per invocation may need
more adjustment.
The previous implementation could stall UI progress for some 20-30s.
This change lets users perceive UI progress while sample memory gets
retrieved and interpreted.
This resolves bug #1005.
Recent commits added "position tracking" for interesting spots in the
sample stream and the current iteration pointer. Which obsoletes the
counters for remaining items until trigger, the "triggered here" flags,
as well as the unfortunate "rewind a little" workaround which lacked a
comment on its motivation or implementation details.
The hardware provided trigger match location is inaccurate. Do check
sample values against the initial trigger condition spec for a short
range of the retrieved sample data, to refine the trigger marker's
position which is sent to the session feed.
Temporarily ignore the optional sample count limit for trigger-using
acquisitions, to reduce the diff size and simplify review. Since the
hardware transparently compresses sample data, we cannot reliably
determine where to start the download and interpretation of sample data,
and the submission to the session feed. Starting early in the sample
memory content, and sticking with the strict sample count limit, could
clip submission before the actual trigger position.
This implementation provides _at least_ the requested amount of data,
and does cover the spot of interest (the trigger position). This, and
the trigger support's having become operational again, is considered an
important improvement. The inaccuracy is considered acceptable for now.
Trigger-less acquisition does enforce the exact sample count limit.
Rephrase how the sample memory iteration position gets tracked, increment
after every event slot already. Update the "last seen sample" status more
often (an event slot can hold several sample items). Arrange for a period
of time where software will check sample data for trigger matches. This
improves the precision of the hardware provided trigger match location.
Do send hardware provided trigger locations to the session feed even if
the software check found no match on the data content. This covers user
initiated button presses (which can unblock the acquisition when the
application provided trigger condition never matches).
Note that this implementation does manage the window of supervision, but
does not yet check the sample values against the trigger condition. This
gets added later.
Factor USB data transfer out of the code path which interprets sample
memory content. Keep internal state of sample memory download in the
device context. This eliminates local variables, and ideally allows a
future implementation to spread chunked downloads across several read
callbacks, which would improve UI responsiveness.
Update comments while we are here. Address minor portability nits (ull
suffix vs UINT64_C macro). The inner loops (iterating clusters and their
events which contain individual samples) are not affected by this commit.
Further rephrase the sigma_write_trigger_lut() routine. It's helpful to
"think" in BE16 quantities to improve readability of LUT address and
parameter downloads. Better matches the vendor's documentation. Also use
a better name for the "trigger select 2" register content.
Start moving parameters into the device context which are related to the
interpretation of sample memory content. This can simplify error paths,
allow to release resources late. And ideally sample memory download and
interpretation could spread across several receive callbacks, improving
UI responsiveness. Also makes total and current dimensions available to
deeper nesting levels in the interpretation, which currently don't have
access to these details.
Create a sub struct in the device context which keeps those parameters
which are related to sample memory interpretation. Which also obsoletes
the 'state' struct and only leaves the 'state' enum as a remainder.
Use the "samples per event" condition instead of the samplerate when
extracting a number of samples from an event's storage. Rename the
de-interleaving routines to better reflect their purpose.
Mechanically adjust the add_trigger_function() routine to address nits,
attempt to improve maintainability.
Raise awareness of the fact that strict binary arithmetics is done (bit
operators are used), the strict 0..1 set of values needs to be enforced,
and mere "logical truthness" is not good enough in this spot. Explicitly
check for bit positions instead of "shifting out" the bit of interest
and have the 0/1 value result nearly by coincidence.
Extend comments. Group related instructions and separate them from other
groups. Reduce the scope of the rather generic i, j, tmp named variables
which are just too easy to get wrong.
Rename macros to better reflect which of them check a bit position, and
which span a bit field of given width. Adjust more call sites to use the
macros. This takes tedium out of maintenance as well as review. Has the
minor benefit of somewhat shortening text lines, and eliminating nested
parentheses (or getting perceived as if it would).
Move the acquisition limits related variables into a sub struct within
the device context. Over time they became numerous, and might grow more
in the future.
There are several separate conditions which the driver needs to tell
apart. There is a compile time switch whether trigger support shall be
built in. There is the condition whether acquisition start involved a
user provided trigger spec. And there is the hardware flag whether a
previously configured trigger condition matched and where its position
is.
Only accept user provided trigger specs when trigger support is builtin.
(The get/set/list availability and spec passing is done in applications
outside of the library, we better check just to make sure.) Only setup
the trigger related hardware parameters when a spec was provided. Only
check for trigger positions when the hardware detected a match.
Enable the compile time option which builds trigger support code into
the asix-sigma driver. This is a development hack. Trigger support in
the driver is incomplete and currently not operational.
Address remaining data type nits. Use more appropriate types for sizes
and counters and indices, as well as for booleans.
Prefer more verbose variable names in a few spots to avoid the rather
generic 'i' symbol, especially in complex code paths with deeply nested
flow control or with long distances between declaration and use. Re-use
an existing buffer in the acquisition start for command sequences which
setup trigger in/out as well as clock parameters.
Introduce some variables which may seem unnecessary. But these are
useful for research during maintenance.
This is a mechanical adjustment, behaviour does not change.
Introduce the required infrastructure to store successfully applied
configuration data in hardware registers. This lets the probe phase of
the next sigrok session pick up where the previous session left. Which
improves usability, and increases performance by eliminating delays in
the acquisition start, by not repeating unnecessary firmware uploads.
The vendor documentation suggests there would be FPGA registers that are
available for application use ("plugin configuration"). Unfortunately
experiments show that registers beyond address 0x0f don't hold the data
which was written to them. As do unused registers in the first page. So
the desirable feature is not operational in this implementation. There
could be different netlist versions which I'm not aware of, or there
could be flaws in this driver implementation. This needs more attention.
Stop assuming that C language variables whould have a specific memory
layout that applications could rely on. Use normal data types in higher
abstraction layers, drop non-portable bit fields. Use existing macros
for the creation of bit masks of a given width.
Eliminate doubt from a comment on ASIX SIGMA's channel names which was
introduced in commit d261dbbfcc. Publicly available documentation does
agree their names start at "1" and go up to "16".
The 50MHz netlist supports the use of an external clock. Any of the 16
channels can use any of its edges to have another sample taken from all
the other pins. It's nice that the hardware does track timestamps, which
results in an exact reproduction of the input signals' timing with 20ns
resolution, although the clock is externally provided and need not have
a fixed rate.
Rephrase more parts of sigma_build_basic_trigger() to closer match the
vendor documentation. Use the M3Q name. Be explicit about "parameters"
setup (even if that means to assign zero values, comments help there).
Using three BE16 items for the parameters improves readability.
Rephrase the sigma_build_basic_trigger() and build_lut_entry() routines
to hopefully improve readability. Avoid the use of short and generic
identifiers which are just too easy to confuse with each other and the
1 literal and negation operator in deeply nested loops and complex
expressions that span several text lines. Reduce indentation where
appropriate. Concentrate initialization and use of variables such that
reviewers need less context for verification.
This is a purely mechanical change, the function of triggers remains
untested for now. Setting "selres" in that spot is suspicious, too.
Rephrase the sigma_write_trigger_lut() routine to work on "a higher
level" of abstraction. Avoid short and most of all generic variable
names. Use identifiers that are closer to the vendor documentation.
Reduce the probability of errors during maintenance, and also increase
readability. Replace open coded nibble extraction and bit positions by
accessor helpers and symbolic identifiers. Adjust existing math where it
did not match the vendor documentation. Always communicate 8bit register
addresses, don't assume that application use remains within a specific
"page". Provide more FPGA register access primitives so that call sites
need not re-invent FPGA command sequence construction. Remove remaining
open coded endianess conversion in DRAM access.
The 100/200MHz supporting FPGA netlists differ in their register set
from 50MHz netlists. Adjust the parameter download at acquisition start.
Raise awareness of the "TriggerSelect" and "TriggerSelect2" difference
(the former only exists in 50MHz netlists, the latter's meaning differs
between firmware variants). "ClockSelect" semantics also differs between
netlists. Stop sending four bytes to a register that is just one byte
deep, channel selection happened to work by mere coincidence.
Eliminate a few more magic numbers, unobfuscate respective code paths.
Though some questions remain (trigger related, not a blocker for now,
needs to get addressed later).
Make the list of supported samplerates an internal detail of the
protocol.c source file. Have the api.c source file retrieve the list
as well as the currently configured value by means of query routines.
Ideally the current rate could get retrieved from hardware at runtime.
A future driver implementation could do that. This version sticks with
the lowest supported rate, as in the previous version.
Sort "semi public" routines and "global data" of the asix-sigma driver
in the protocol.h header file by their use. Add comments. This improves
maintenance of the driver source.
Move all of the FTDI connection handling from api.c to protocol.c, and
prepare "forced" and "optional" open/close. This allows future driver
code to gracefully handle situations where FPGA registers need to get
accessed, while the caller may be inside or outside the "opened" period
of the session. This is motivated by automatic netlist type and sample
rate detection, to avoid the cost of repeated firmware uploads.
Detect more error conditions, and unbreak those code paths where wrong
data was forwarded. It's essential to tell the USB communication layer,
sigrok API error codes, and glib mainloop receive callbacks apart. Since
the compiler won't notice, maintainers have to be extra careful.
Rephrase diagnostics messages. The debug and spew levels are intended
for developers, but the error/warn/info levels will get presented to
users, should read more fluently and speak from the application's POV.
Allow long text lines in source code, to not break string literals which
users will report and developers need to search for (this matches Linux
kernel coding style).
This commit also combines the retrieval of sample memory fill level,
trigger position, and status flags. Since these values span an adjacent
set of FPGA registers. Which reduces USB communication overhead, and
simplifies error handling. The helper routine considers the retrieval
of each of these values as optional from the caller's perspective, to
simplify other use cases (mode check during acquisition, before sample
download after acquisition has stopped).
INIT pin sensing after PROG pin pulsing was reworked, to handle the
technicalities of the FTDI chip and its USB communication and the FTDI
library which is an external dependency of this device driver. Captures
of USB traffic suggest that pin state is communicated at arbitrary times.
Address minor style nits to improve readability and simplify review. The
sizeof() expressions need not duplicate data type details. Concentrate
the assignment to, update of, and evaluation of variables in closer
proximity to reduce potential for errors during maintenance. Separate
the gathering of input data and the check for their availability from
each other, to simplify expressions and better reflect the logic's flow.
Further "flatten" the DRAM layout's declaration for sample data. Declare
timestamps and sample data as uint16_t, keep accessing them via endianess
aware conversion routines. Accessing a larger integer in smaller quantities
is perfectly fine, the inverse direction would be problematic.
Keep application data in its logical presentation in C language struct
fields. Explicitly convert to raw byte streams by means of endianess
aware conversion helpers. Don't assume a specific memory layout for
C language variables any longer. This improves portability, and
reliability of hardware access across compiler versions and build
configurations.
This change also unobfuscates the "disabled channels" arithmetics in
the sample rate dependent logic. Passes read-only pointers to write
routines. Improves buffer size checks. Reduces local buffer size for
DRAM reads. Rewords comments on "decrement then subtract 64" during
trigger/stop position gathering. Unobfuscates access to sample data
after download (timestamps, and values). Covers a few more occurances
of magic numbers for memory organization.
Prefer masks over shift counts for hardware register bit fields, to
improve consistency of the declaration block and code instructions.
Improve maintenability of the LA mode initiation after FPGA netlist
configuration (better match written data and read-back expectation,
eliminate magic literals that are hidden in nibbles).
Move the 'devc' parameter to the front in routine signatures for the
remaining locations which were not adjusted yet. Reduce indentation of
continuation lines, especially in long routine signatures. Try to not
break string literals in diagnostics messages, rephrase some of the
messages. Massage complex formulae for the same reason.
Whitespace changes a lot, word positions move on text lines. See a
corresponding whitespace ignoring and/or word diff for the essence of
the change.
The driver got extended in a previous commit to accept any hardware
supported samplerate in the setter API, although the list call does
suggest a discrete set of rates (a subset of the hardware capabilities).
Update a comment to catch up with the implementation.
Drop the 250kHz item, it's too close to 200kHz. Add a 2MHz item to
achieve a more consistent 1/2/5 sequence in each decade. Unfortunately
50MHz and an integer divider will never result in 20MHz, that's why
25MHz is an exception to this rule (has been before, just "stands out
more perceivably" in this adjusted sequence).
Running several firmware uploads in quick repetition sometimes failed.
It's essential to stop the active netlist from preventing the FPGA's
getting reconfigured (FTDI to FPGA pins are so few, and shared). Delays
in a single iteration of the initiation sequence improves reliability.
Retries of the sequence are belt and suspenders on top of that.
Before the change, failure to configure was roughly one in ten. After
the change, several thousand reconfigurations passed without failure.
Use symbolic identifiers to select firmware images, which eliminates
magic 0/1/2 position numbers in the list of files, improves readability
and also improves robustness. Move 'devc' to 'ctx' and before other
arguments in routine signatures while we are here.
FPGA configuration (netlist upload) of ASIX SIGMA devices is rather
special a phase, and deserves its own state in the device context's
"state" tracking. Not only is the logic analyzer not available during
this period, the FTDI cable is also put into bitbanging mode instead
of regular data communication in FIFO mode, and netlist configuration
takes a considerable amount of time (tenths of a second).
Use common support for SW limits, and untangle the formerly convoluted
logic for sample count or time limits. Accept user provided samplerate
values when the hardware supports them, also those which are not listed.
The previous implementation mapped sample count limits to timeout specs
which depend on the samplerate. The order of applications' calls into
the config set routines is unspecified, the use of one common storage
space led to an arbitrary resulting value for the msecs limit, and loss
of user specified values for read-back.
Separate the input which was specified by applications, from limits
which were derived from this input and determine the acquisition phase's
duration, from sample count limits which apply to sample data download
and session feed submission after the acquisition finished. This allows
to configure the values in any order, to read back previously configured
values, and to run arbitrary numbers of acquisition and download cycles
without losing input specs.
This commit also concentrates all the limits related computation in a
single location at the start of the acquisition. Moves the submission
buffer's count limit container to the device context where the other
limits are kept as well. Renames the samplerate variable, and drops an
aggressive check for supported rates (now uses hardware constraints as
the only condition). Removes an unused variable in the device context.
Introduce a 4MiB session feed submission buffer in the device context.
This reduces the number of API calls and improves performance of srzip
archive creation.
This change also eliminates complex logic which manipulates a previously
created buffer's length and data position, to split the queued data when
a trigger position was involed. The changed implementation results in a
data flow from sample memory to the session feed which feels more natural
during review, and better lends itself to future trigger support code.
Use common SW limits support for the optional sample count limit. Move
'sdi' and 'devc' parameters to the front to match conventions. Reduce
indentation in routine signatures while we are here.
This implementation is prepared to handle trigger positions, but for now
disables the specific logic which checks for trigger condition matches
to improve the trigger marker's resolution. This will get re-enabled in
a later commit.
Add more symbolic identifiers, and rename some of the existing names for
access to SIGMA sample memory. This eliminates magic numbers and reduces
redundancy and potential for errors during maintenance.
This commit also concentrates DRAM layout related declarations in the
header file in a single location, which previously were scattered, and
separated registers from their respective bit fields.
Extend comments on the difference of events versus sample data.
Move the FPGA commands (which can access registers, and sample memory)
declarations before the register layout declaration. Which then no
longer separates the registers declarations from their bit fields.
Update comments on the register set while we are here.
Eliminate a few magic numbers in FPGA commands, use symbolic identifiers
for automatic register address increments, and DRAM access bank selects.
Improve grouping of related declarations in the header file.
Slightly rephrase and comment on the FPGA configuration of the ASIX
SIGMA logic analyzer. Use symbolic pin names to eliminate magic numbers.
Concentrate FPGA related comments in a single spot, tell the Xilinx FPGA
from FTDI cable (uses bitbang mode for slave serial configuration).
This fixes typos in the PROG pulse and INIT check (tests D5 and comments
on D6). Also removes the most probably undesired 100s timeout in the
worst case (100M us, 10K iterations times 10ms delay). Obsoletes labels
for error paths. Drops a few empty lines to keep related instruction
blocks together. Includes other style nits.
Stick with the FTDI library for data acquisition, and most of all for
firmware upload (bitbang is needed during FPGA configuration). Removing
this dependency is more complex, and needs to get addressed later.
Re-use common USB support during scan before open, which also allows to
select devices if several of them are connected. Either of "conn=vid.pid"
or "conn=bus.addr" formats are supported and were tested.
This implementation detects and displays SIGMA and SIGMA2 devices. Though
their function is identical, users may want to see the respective device
name. Optionally detect OMEGA devices, too (compile time option, off by
default), though they currently are not supported beyond detection. They
just show up during scans for ASIX logic analyzers, and users may want to
have them listed, too, for awareness.
This implementation also improves robustness when devices get disconnected
between scan and use. The open and close routines now always create the
FTDI contexts after the code has moved out of the scan phase, where common
USB support code is used.
This resolves bug #841.
Eliminate an unnecessary magic number for the maximum filename length of
SIGMA netlists. Use a more compact source code phrase to "unclutter" the
list of filenames and their features/purpose. Move the filesize limit to
the list of files to simplify future maintenance.
The UT32x driver requires a user spec for the connection. The device
cannot get identified, that's why successful open/close for the port
will suffice. Lack of an input spec as well as failure in the early
scan phase will terminate the scan routine early.
When we reach the end of the scan which creates the device instance
and registers it with the list of found devices, the port already
is closed and the list of devices will never be empty. Remove the
redundant close call and the dead branch which frees the serial port.
src/hardware/siglent-sds/protocol.c: In function 'siglent_sds_get_digital':
src/hardware/siglent-sds/protocol.c:382:35: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (data_low_channels->len <= samples_index) {
^
src/hardware/siglent-sds/protocol.c:391:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
if (data_high_channels->len <= samples_index) {
^
src/hardware/siglent-sds/protocol.c:417:32: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (long index = 0; index < tmp_samplebuf->len; index++) {
^
In file included from src/hardware/siglent-sds/protocol.c:37:0:
src/hardware/siglent-sds/protocol.c: In function 'siglent_sds_receive':
src/hardware/siglent-sds/protocol.h:28:20: warning: format '%li' expects argument of type 'long int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "siglent-sds"
^
./src/libsigrok-internal.h:815:41: note: in expansion of macro 'LOG_PREFIX'
#define sr_dbg(...) sr_log(SR_LOG_DBG, LOG_PREFIX ": " __VA_ARGS__)
^
src/hardware/siglent-sds/protocol.c:564:6: note: in expansion of macro 'sr_dbg'
sr_dbg("Requesting: %li bytes.", devc->num_samples - devc->num_block_bytes);
^
src/hardware/siglent-sds/protocol.c: In function 'siglent_sds_get_dev_cfg_horizontal':
src/hardware/siglent-sds/protocol.h:28:20: warning: format '%lu' expects argument of type 'long unsigned int', but argument 3 has type 'uint64_t {aka long long unsigned int}' [-Wformat=]
#define LOG_PREFIX "siglent-sds"
^
./src/libsigrok-internal.h:815:41: note: in expansion of macro 'LOG_PREFIX'
#define sr_dbg(...) sr_log(SR_LOG_DBG, LOG_PREFIX ": " __VA_ARGS__)
^
src/hardware/siglent-sds/protocol.c:933:2: note: in expansion of macro 'sr_dbg'
sr_dbg("Current memory depth: %lu.", devc->memory_depth_analog);
^
Changing triggers (e.g. from low to high) would sometimes cause the
acquisition to seemingly "hang" due to missing variable initializations
(in reality the device would wait for incorrect triggers and/or on
incorrect channels).
This fixes bug #1535.
Gerhard Sittig
Timo Kokkonen
Mike Walters
Wolfram Sang
Soeren Apel
Valentin Ochs
motte
Andy Lutomirski
Walter Goossens
Florian Schmidt
Uwe Hermann
Andreas Sandberg
Frank Stettner
Tobias Faeth
Sergey Rzhevsky
Richard
Jan Metzger
Christian Fruth