Introduce a bm52x DMM packet parser which is modelled after the bm86x
implementation, and hook it up to the serial-dmm driver. This supports
the live readings (real-time download) of the Brymen BM525s logging DMM.
The timing follows the vendor documentation (0.5s between requests, and
4.0s absolute timeout after request transmission). Reading previously
recorded data (memory data sets) unfortunately does not fit well into
the serial-dmm approach, and needs to get addressed differently later.
Common conversion support code accepts double precision input data for
analog packets. Use the 'double' data type in the CSV input module to
feed sample data to the session bus.
Rephrase the sr_analog_to_float() routine to further reduce redundancy.
Check early for a match of the input data and result format, to grab the
raw data without conversion in that case. Handle optional scale/offset
calculation in that fast code path, too.
Unify the instructions which convert input data from either integer or
floating point presentations to the result format. Use common stream
readers to retrieve input data in several formats, which eliminates
local conversion buffers. Move common sub-expressions (scale/offset) out
of loops. Run more calculations on double precision data before results
get trimmed to single precision.
Add and extend comments to improve future maintenance. Include (terse)
details of unsupported input data presentations in error messages.
This implementation was neither tuned nor measured for performance.
There still is a lot of redundancy among the branches which handle a
specific input data type. Rephrasing that approach interacts with the
yet to be done performance tuning, thus needs to get addressed later.
The current phrases' verbosity is believed to improve readability.
Add endianess aware readers including address incrementing variants for
those intrinsic data types which were missing in the previous version
yet are needed for sr_analog_to_float() adjustment.
Also move the 24bit reader to its position in the sort order.
Extend test coverage for the sr_analog_to_float() conversion routine.
Pass data which is encoded in native, little and big endian format to
the routine. Pass single and double precision floating point data, and
integer data in different unit sizes and signedness. Cover scale/offset
calculations as well.
Also cover expected failed conversion for unsupported combinations of
input data format details (half/quad precision float, u64 integer).
Adjust the grouping of test cases in the sequence while we are here.
Move SI prefix, unit, and rational number related tests out of the
analog-to-float conversion group.
Unbreak the conversion of input data in the floating point format when
the input data's format does not match the host's internal presentation,
thus grabbing raw data cannot be done.
Also accept the input data in double precision format which was not
supported before. Check for unsupported unit size values and emit an
error message similar to the integer code path.
This is motivated by bug #779 but does not resolve it. Adjusts common
conversion support, but sticks with single precision return data type
for API compatibility.
We pass no message, so use ck_assert instead of ck_assert_msg. This
results in an error with check 0.15:
tests/strutil.c:157:2: error: too few arguments to function '_ck_assert_failed'
157 | ck_assert_msg(saved_locale != NULL);
The Saleae Logic exported files (Logic2 digital format) don't contain a
samplerate, so users need to specify the value. For values smaller than
the samplerate that was used during the capture undersampling will take
place. An implementation detail of the input module could result in
incorrect timing of sample values in the session feed. In extreme cases
none of the periods between signal edges qualified for submission. In
that case no sample data was sent to the sigrok session at all.
$ sigrok-cli -i digital_1.bin -I saleae:samplerate=1000
Keep the very timestamp at hand when the last sample data was submitted.
Only advance that timestamp when more sample data was sent. This avoids
the accumulation of timing errors for undersampling scenarios, and does
forward undersampled input data when the user provided sample period has
passed.
This fixes bug #1600.
The korad response read routine clears the receive buffers, so callers
don't have to. This amends commit d2cc60bd45.
The acquisition timeout is handled by common sw_limits support. Remove
the no longer referenced literal. This amends commit 3f9b48ae5f.
The Korad protocol relies on unterminated request and response strings,
which works well enough for fixed length acquisition and status queries.
But the variable length replies to identification requests suffered from
an implementation detail in the receive routine. A large timeout must be
used because supported devices reportedly are slow to respond. There is
no simple yet robust condition to detect the response's completion. The
scan code must prepare for the maximum response length across the set of
supported devices. Unfortunately the maximum amount of time was spent
waiting for the response to occupy the provided response buffer, before
a long total timeout expired.
Rework the korad driver's helper routine which gets a variable length
non-terminated text string. Keep the long initial timeout, and keep
iterating in that initial phase to quickly detect when response data
became available. But terminate the read sequence after a shorter period
without receive data after some initial receive data was seen. Assume
that identification responses get transferred at wire speed and without
additional delays beyond bitrate expectations. Acquisition and status
responses shall not be affected by this change.
This speeds up the scan for devices from roughly 5s to some 0.1s on
newer devices (KA3005P v5.5) and 0.5s on older devices (KA3005P V2.0).
This commit also addresses an issue in the response text termination,
where partial responses contained undefined data. The previous version's
return value was unspecific: Negative for fatal errors, but either zero
or non-zero for successful reads, with no way for callers to learn about
the received amount of data. The rephrased version always returns the
amount of received data, and adds internal documentation which discusses
the implementation's constraints and the motivation for the approach.
This is a modified version of the initial implementation which was
Submitted-By: Karl Palsson <karlp@tweak.net.au>
Cleanup style in the korad driver's scan() routine. Keep declarations
out of code blocks. Reduce redundancy and improve robustness in the
response buffer length calculation. Reduce clutter and group related
instructions together. Unobfuscate result checks, and keep the result
at hand (for diagnostics, or error propagation). Unobfuscate string
comparisons in the model ID lookups, terminate the search upon match.
Use a not so terse name for data that gets referenced at rather distant
locations.
Keep the optionally available serial number at hand, to present it to
users when desired. This aspect was
Reported-By: Karl Palsson <karlp@tweak.net.au>
The previous implementation of the cleanup() routine in the saleae input
module kept user specified options, but lost the previously created list
of sigrok channels. Keep it.
Also make sure that reset() voids the previous copy after grabbing its
value. To not unexpectedly release resources which still get referenced.
This shall unbreak file-reload.
Stop using the unusal "mixed" mode (local interface available during
remote operation) for HMP4000, applications may not be prepared for this
use case. Use traditional "remote" and "local" modes instead. This change
also ends remote mode after the application is done using the device.
List both vendor names "HAMEG" and "ROHDE&SCHWARZ" in the scpi-pps
driver, either responses were seen for HMP4000 devices. Unfortunately
vendor names don't support regex matches, so they require individual
profile items. The items also "violate" the alpha sort order in the list
of profiles, but keeping the series' models together is more important.
Add a declaration for the HMP4030 device which re-uses the HMP4040 data
but open codes the smaller channel count. Ideally the .probe_channels()
routine would receive the scpi_pps item as a parameter, and could yield
model specific result data from common information for the series. The
implementation in this commit is the least intrusive approach until
something better becomes available.
This shall cover the whole HMP4000 series:
https://www.rohde-schwarz.com/product/hmp4000
This commit introduces initial support for the HMP4040 power supply by
Rohde & Schwarz. It allows to configure the device and "statically" read
back current state. Automatic status updates with per-channel details
are not available yet (common support is missing).
[ gsi: drop status update remainder, address minor style nits ]
Reference the vendor's Windows specific "driver" download for the
CP210x chip with a non-default VID:PID. Provide an example how to
assign the Linux driver to that device (interactive, no udev rule).
In the current implementation the "flags" are exclusively used for
captures. Prepare the introduction of device flags by renaming the
capture related flags which are specific to an operation.
Reviewed-By: Wolfram Sang <wsa@kernel.org>
Unconditionally generate output text when a session packet is received
which carries analog or logic sample data. Even if the data gets queued
and is not shown immediately, in that case the output text remains empty
but needs to be present. Otherwise applications may assume that the CSV
output module had not handled the data at all, which would result in
unexpected "screen output" with fallback data being interleaved with the
CSV output.
This resolves bug #1026 in its strictest sense (the unexpected presence
of fallback data). But leaves all other issues mentioned in comment 1.
The current implementation of the CSV output module makes assumptions
which don't hold. Which results in incorrect or incomplete output for
some combinations of logic and analog signals.
Check for some of the known problematic conditions, and warn the user
about potentially unexpected results. This is a workaround until the
issues properly get addressed in the implementation.
This is motivated by but does not resolve bug #1026.
Korad PSU models are rather popular. But the successful operation of
currently unsupported model names or firmware versions is hard to verify
by users, because building the library from locally modified sources is
involved.
Introduce support for the "force_detect=" scan option. Warning messages
contain how the device identifies itself. Optional user specs can force
the assignment of the driver to the unsupported model. Which results in
reports that include the identification details as well as the successful
use of the device.
$ sigrok-cli -d korad-kaxxxxp:conn=...:force_detect=KORADKA3005PV2.0 --show
Often previously unsupported models might be covered by existing code,
but would not match against a builtin list of known devices.
Introduce a config key which provides a scan option for users to force
the use of a driver with an unsupported device. This increases the
probability of requests for support of an additional model which are
associated with a successful use of that very device, and eliminates
the necessity to build from source for the trivial cases.
It's up to individual drivers whether they support forced detection,
and how they interpret the value of the scan option.
Let applications query the device instance's conn= key. This lets users
recognize individual devices if multiple of them are connected.
$ sigrok-cli -d korad-kaxxxxp:conn=/dev/ttyACM0 --show
...
korad-kaxxxxp:conn=/dev/ttyACM0 - Korad KA3005P with 2 channels: V I
...
Add new command DMM_CMD_SETUP_LOCAL for setting device back
to "local" mode. If device implmements this command, it is
sent when driver is closed and after device "scan".
Define DMM_CMD_SETUP_LOCAL for GWInstek meters, so they get
returned to local mode automatically after use.
Any order is as arbitrary as any other. The alphabetical order of vendor
and model names might be the most robust during maintenance: easiest to
remember, easiest to use when checking for presence, and easiest to add
to or resolve conflicts during merges. Vendor renames (HP to Agilent to
Keysight, et al) are ugly but can't be helped easily.
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.
Raise the diagnostics message's severity from debug to warn when the
'*IDN?' response lacks the serial number field. Although it has only
been seen for some GWInstek DMMs, it violates the SCPI spec, and more
or other activity is required in a future implementation. This change
amends commit 47e7a6395e.
Rearrange the check for line termination in SCPI receive data, and add a
comment in that spot. Keep related conditions together, avoid line breaks
for complex terms. This shall simplify review, and raise awareness during
maintenance. This change amends commit a0ade2f933.
Gerhard Sittig
Timo Kokkonen
Jiri Slaby
Florian Schmidt
v1ne
Frank Stettner