Extend the BM52x packet parser, add config get/set/list code to handle
the data source property. Either let the common serial-dmm code run the
acquisition of live readings, or locally retrieve the selected "session
page" and forward its measurements to the session bus. These separate
code paths are required because the protocol differs a lot between these
modes, a totally different set of requests and responses is involved,
response interpretation logic is impossible to share between live and
recorded measurements.
Implement a DMM packet parser for the BM850s protocol. This involves
variable length responses, which recently became a common serial-dmm
feature. Register the new parser under the "brymen-bm85x" device name.
This obsoletes the brymen-dmm driver which announces as "brymen-bm857".
This implementation was tested with the BM859s meter.
The text to number conversion with precision detection resolves the
last remaining issue of bug #1611.
Extend the serial-dmm driver's common infrastructure to support more
per-parser (per-model) specific extensions. Add support for variable
length packets (motivated by BM85x), and pass the packet length to
parsers which accept it. Add callbacks which run after the COM port got
opened (motivated by BM85x). Add support for additional configuration
get/set/list properties (motivated by BM52x), including a hook into the
acquisition start and a state container which is owned by the parser.
Device specific acquisition start can check its local state which can
store the result of previous config get/set requests, and can arrange
for a different receive routine to execute (motivated by BM52x). The
default code path will execute serial-dmm's receive routine which keeps
invoking the DMM's packet parser for each registered display.
Prefer double precision values in the new parser callbacks. Also fixup
some data type issues: Use unsigned types for length and size specs as
well as timeouts, don't promote false booleans to NULL pointers, reduce
malloc() argument redundancy. Rephrase some instruction grouping and
update comments to simplify future maintenance. Get the current time
just once for improved consistency in the packet re-request code path.
Rename identifiers in the data reception path to improve readability.
The previous implementation of the packet detection in a serial stream
assumed that all packets are of equal length which is known in advance.
Extend the packet validity check interface such that caller provided
callbacks can either decide that the input is valid or invalid (terminal
decision), or request more receive data before a decision can be made
(deferral, coverring variable length packets, with a minimum size to
cover the header before a length becomes available and the total packet
length is known).
This commit extends the API, and adjusts the call sites to not break the
compilation. Actual variable length checkers are yet to be done. Improve
readability while we are here: Better reflect the purpose and units of
variables in their identifiers. Tweak diagnostics messages, update
inline and doxygen comments.
DG800/DG900 units seems to have issues with counter implementation:
- About 1 second delay is needed after enabling or disabling the counter.
Otherwise unit stops responding properly (start seeing USB errors).
- Second channel and counter cannot be enabled simultaneously.
Strictly speaking the "new" identifier is not a reserved word. Still
it's good practice not to use it for variables in C language sources.
Rename variables to "old_bit" and "new_bit" for consistency.
Rearrange the order of declarations in the protocol.h header. Start with
packet layout, continue with requests (commands), then responses (status),
before the device context and the set of routines.
Rename the status codes to STS_* in contrast to CMD_* codes. Use an enum
for different byte values, leave defines for packet sizes et al. Phrase
bit fields in terms of bit numbers not byte values.
Total nit: Change the breaks in the long list of add_source() args. Keep
event type and timeout together, similar to callback and its data.
Explicitly "break the flow" when internal status gathering fails, to
reflect that an error path is taken and the config call will fail. The
conditional assignment of response data in case of success could be
slightly misleading (it was to me during review).
Eliminate a goto which kind of circumvented the optional transmission of
a request to the device. Instead test whether a command was filled in to
determine whether a command needs to get sent.
This driver supports ITECH IT8500 series electronic loads:
IT8511+, IT8511A+,
IT8512+, IT8512A+, IT8512B+, IT8512C+, IT8512H+,
IT8513A+, IT8513B+, IT8513C+, IT8514C+, IT8514B+, IT8516C+
Additionally BK Precision 8500 series loads (models 8500, 8502, 8510,
8512, 8514, 8518, 8520, 8522, 8524 & 8526) should work as well.
As ITECH is the OEM manufacturer for these BK Brecision models.
Reading output signal duty cycle value didn't always work, since it relied
on old (cached) information about the currently active waveform. Changed to
always query channel status so this won't happen anymore.
Data was sent to the serial port, and the non-zero positive write length
was mistaken as an error, since it did not match the SR_OK code's value.
This snuck in with commit 379e95c587 in 2017-08.
Rephrase the check for successful serial writes in the pce-322a driver.
Pass on error codes from the serial layer in verbatim form. Check for
the exact expected write length and derive SR_ERR_IO upon mismatch. Do
return SR_OK upon success.
Reported-By: Michael Ströder <michael@stroeder.com>
Tested-By: Michael Ströder <michael@stroeder.com>
No need to duplicate the data type, just allocate enough memory to
hold the variable's value. Shuffle the order of items in the array
size calculation (number of items times the size of an item).
This implements support for Rigol DG1000z series digital signal
generators. Driver provides basic control via channel groups
("1", and "2"). Acquisition returns data from the built-in
frequency counter.
Supported models: DG1022Z, DG1032Z, DG1062Z
[ gsi: added some coding style adjustment ]
Use the existing ols_send_reset() routine because acquisition
termination can get initiated in several code paths. Make sure the
device will cease activity whatever state it happens to be in. This
amends commit 6d8182b643.
Sending CMD_RESET will interrupt armed/untriggered acquisitions which is
very useful in Pulseview sessions since, without this, a next 'run' will
hang.
Signed-off-by: Ben Gardiner <ben.l.gardiner@gmail.com>
The reference impedance for dBm measurements comes in an unexpected
format. Isolate the 4..1200 Ohms value, ignore the (inappropriate?)
"0." and exponent parts of the response. Clearly reflect that Ohms
values are seen in different contexts (dBm reference, continuity,
resistance).
Reword comments in the BM850 response parser's code path for dBm
measurements. The reference value is shown when the function is entered
(verified here) or when the reference value changes (haven't seen this
here but a comment in the previous implementation said so).
The BM850s temperature function response includes the C/F unit in an
unexpected position ("0.0272CE+3") which breaks number conversion. Drop
the C/F unit to unbreak the conversion.
This was observed with BM859s. Absence of the C/F unit in the response
is fatal in this implementation. If other meter firmware versions or
models don't suffer from that issue, the removal must be silent and
non-fatal.
When the BM850s response packet's payload gets interpreted, the DLE/STX
transport envelope is not of interest. Rephrase the bitfield inspection
to better reflect that 'bfunc' indicators get accessed (match the vendor's
documentation). Rephrase the calling parse routine to unobfuscate the text
field access. Unclutter assignments for the analog feed. Use a shorter
layout in debug messages, reflect raw input data and conversion results.
The BM850(a/s) response packets are a mix of binary and text content.
The text part of it is _not_ a regular ASCIIZ string. Enforce the NUL
termination before running standard C library string routines on it.
Rephrase the conversion routine to become more C idiomatic.
Also check the optional sign for overflow conditions, return either
positive or negative infinity as a result.
Rephrase how the default serial communication parameters get applied.
Preset the variable to the default value and let optional user provided
specs override these. This avoids an extra check which is difficult to
read and highly redundant. Add a comment for raised awareness that a
default port spec is undesirable because it's unreliable.
Raise the severity of low battery messages. It's worth warning the user
because measurements could be inaccurate.
Reduce indentation in continuation lines of a long routine signature,
and drop an empty line in a short struct while we are here.
Either the Brymen meters in the BM850s series or their cables require an
RTS pulse to wakeup, without it there won't be a response during scan or
when requesting measurements. Follow the vendor's documented sequence for
a low RTS pulse after opening the serial port and before communication to
the device.
This fixes bug #1595.
Reported-By: Karl Palsson <karlp@tweak.net.au>
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.
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>
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 ]
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>
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
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.
Gerhard Sittig
Timo Kokkonen
Ben Gardiner
Florian Schmidt
v1ne
Frank Stettner