Introduce a DMM packet parser in src/dmm/ and register it with the
serial-dmm device driver. This adds support for the Meterman 38XR
multimeter.
[ gsi: style adjustment, raise awareness during maintenance ]
The BM820s series uses the same 10000 counts protocol as BM520s does,
but lacks the capability of recording measurements. Re-use the bm52x
DMM packet parser, but don't register the config get/set/list and
acquisition start callbacks.
It turns out that the packet request and packet validity check routines
need to be individual, since 0x82 is used instead of 0x52 as a magic
number in some places. Fortunately the complex payload parser is shared
among BM520s and BM820s series. This was tested with a BM829s meter.
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.
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.
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>
The serial-dmm entry for Victor DMMs is able to communicate to either
geniune COM ports (RS232 or USB CDC) or the obfuscating USB HID cables.
The victor-dmm driver became obsolete and was removed. Rename the
serial-dmm entry, remove the no longer needed "-ser" suffix. Suggest a
default connection via the obfuscating USB HID cable, accept user
provided overrides for regular serial cables (same behaviour as before,
connection spec for serial ports keeps being mandatory).
Request packets from the Brymen BM86x meter much faster. The previous
implementation in the separate driver used to immediately send another
request when a measurement arrived, with a 10ms granularity in the poll
routine, and a 500ms timeout between requests.
Considering the meter's update rate, stick with the 500ms timeout, but
increase the maximum request rate to 10 per second, with a minimum of 2
per second. This receives measurement data at the meter's capability
(compare DC and AC modes, seems to automatically adjust to the internal
operation, and match the display update rate).
Move Brymen BM86x specific packet parse logic to a new src/dmm/bm86x.c
source file, and register the routines with the serial-dmm driver's list
of supported devices. Which obsoletes the src/hardware/brymen-bm86x/
hierarchy.
This implementation differs from the previous version: The parse routine
gets called multiple times after one DMM packet was received. Values for
the displays get extracted in separate invocations, the received packet
is considered read-only. Unsupported LCD segment combinations for digits
get logged. Low battery gets logged with higher severity -- the validity
of measurement values is uncertain after all. The parse routine uses
longer identifiers. Packet reception uses whichever serial transport is
available (need no longer be strictly USB HID nor libusb based). All
features of the previous implementation are believed to still be present
in this version.
This configuration queries measurement values each 0.5 seconds and
re-sends a not responded to request after 1.5 seconds. Which follows the
combination of the vendor's suggested flow (frequency) and the previous
implementation's timeout (3x 500ms). This implementation does not try to
re-connect to the HID device for each measurement, and neither checks
for the 4.0 seconds timeout (vendor's suggested flow). Local experiments
work without these.
Some meters which are supported by the serial-dmm driver don't strictly
require the user's COM port specification. When a known (usually bundled,
or even builtin) cable type is used, we can provide a default conn= spec
and thus improve usability. Prepare the DMM_CONN() macro, accept user
overrides.
The 'conn' field in the device context and the CONN values in the
declarations of supported DMM models seemed inappropriate. They specify
the communication parameters (UART frame format and bitrate), not the
connection (port name). Adjust the respective identifiers.
Also rephrase the evaluation logic. Instead of checking for the absence
of user specs and optionally assigning a fallback value, just preset
from defaults and override from user specs when present. This simplifies
the logic (eliminates a check).
The serial communication timing parameters during probe get determined
from earlier serial port configuration, which obsoletes the redundant
'baudrate' parameter, and eliminates potential inconsistency between
user specified parameters and builtin default values.
The serial_stream_detect() routine needs to estimate the time which is
needed to communicate a given amount of data. Since the serial port got
opened and configured before, the serial communication parameters are
known, and callers need not redundantly specify the bit rate.
Add an "eevblog-121gw" subdriver entry for the EEVblog 121GW multimeter.
Use device dependent channel names instead of the default "P1" etc names.
It's assumed that the device's binary packet data is available at a COM
port. This means that an external BT to UART gateway is required until
BLE communication will be one of libsigrok's native connection types.
Default to the existing "P1" etc naming scheme for analog channels of
serial-dmm subdrivers. Add support for subdriver specific channel names
(which can reference the channel number if they desire). This is useful
for devices with multiple displays, or special purpose devices where
other names than P1 can better reflect the channel's nature.
Commit 556a926d43 introduced support for multiple displays in
subdrivers of serial-dmm, but also changed user visible channel numbers
to start from 0. Restore the previous behaviour, start counting from 1
which users may perceive as more natural (serial-dmm used to start at P1
in the past, scopes start with CH1 as well).
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.
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.
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().
Factor out identical comments on the UART bitrate of ES519xx based
multimeters. These probably got copied from the first item as of 2012
when new items were added in 2014 (the added devices were from the
same vendor and rebadged).
Expand on the fact that the bitrate still is within spec, and does not
harm at all. Strictly speaking the comment could get dropped.
Rafael G. Martins
Peter Skarpetis
Gerhard Sittig
Timo Kokkonen
Wolfram Sang
Tobias Faeth
Elen Eisendle
Vitaliy Vorobyov
Thomas Weißschuh
Uwe Hermann
Matthias Schulz
Mandl
Frank Stettner
Richard