The existing power supply driver for Riden DPS/DPH devices unfortunately
duplicated intimate details of modbus communication and register layout
including interpretation of raw register values across several source
files. Do separate the physical transport and the register layout and
register fields interpretation layers. This brings the driver in line
with the usual api.c and protocol.c arrangement of responsibilities, and
prepares the future addition of other similar devices.
Address a few style nits while we are here. Include <config.h> in all
source files, and alpha-sort include directives. Address minor data type
nits. Reduce indentation in code paths. Propagate more error codes.
Update comments which lagged behind the code, adjust grammer (eliminate
"actual" false friends). Eliminate a few magic numbers and redundancies,
switch to the more recent endianess aware byte stream reader API where
beneficial, to eliminate redundant offset math.
Other nits seem to have gone unnoticed before: The indices of all sigrok
channels were identical (all zero). Signed print formats were used for
unsigned data.
This implementation compiles, but wasn't runtime tested due to lack of
hardware. A rough estimate of transfer volume and transport throughput
suggests that the 10ms cycle time no longer can be kept, may end up
around 25ms (40 cycles per second). This can get avoided by adding more
code to tell the configuration requests, the acquisition start, and the
measurements grabbing during acquisition apart. It's assumed though that
the 10ms glib poll interval did not translate to such fast measurement
gathering. The firmware may typically provide data at lower rates anyway.
The generic source code may look overly complicated or redundant at
first glance, but compilers' generated code will greatly get optimized.
Simplified maintenance because of reduced cognitive load is considered
more important.
Improve readability by addressing the trivial style nits in the driver.
Break the channel list into two times eight instead of nine plus seven
items. Put braces around all branches if one of them has braces. Add
braces to multi line branches despite most of the branch just being a
comment -- it's still many lines. Break extra long text lines, adjust
the position of operators when single expressions span multiple lines.
Drop unnecessary parentheses around single variables and auto
incrementing pointer dereferences. Adjust whitespace especially for
pointer data types, and arith operators.
Eliminate packed structs in the construction and in the reception of
USB transfers, since these are rather non-portable. Use common support
for endianess aware access to byte streams instead. This unbreaks the
driver for MinGW builds, and increases portability and maintainability
on all other sigrok supported platforms.
[ gsi: adjust more locations, improve robustness, fixup style, reword message ]
The ezusb_upload_firmware() routine opens the USB device and selects the
current configuration. The specified value must match the previously read
configuration descriptor. This commit unbreaks the firmware download for
MinGW builds which link against libusb-1.0.20-rc3-event-abstraction-v4.
[ gsi: reworded commit message ]
The SCPI standard requires OPeration Complete command,
but some Owon meters do not implement it. This commit
makes the probe try OPC once, and if it gets no reply
it assumes it is not supported.
Try the identification command up to three times
if the device responds with 'Invalid Character.',
which can happen if the device has buffered part
of a command but not executed it.
Re-use HMP4000 options and channel groups, only keep separate channel
specs for HMP2000 devices. HMP2030 has three identical 32V/5A channels.
HMP2020 has one 10A channel and one 5A channel.
Specs published by R&S suggest that 10A channels support 0.2mA resolution,
while only 5A channels resolve to 0.1mA (up to 1A full scale, 1mA above 1A).
This fixes a bug where the channel group setting would not be overwritten in a
new run, but instead the channel group settings of both runs would be merged
together.
While the raw sample is the actual received data, the expanded sample is the
crucial data I as a developer am interested in seeing. At least if I assume that
the sample expansion works.
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 ]
Make another code path in the Brymen BM52x packet parser optional which
snuck in earlier and broke compilation when serial_comm dependencies are
not met.
Ideally the src/dmm/ parser code would not get built at all in that
case, but building a parser with reduced functionality and not using it
later because its callers are conditional is as good, and is what other
DMM packet parsers did in the past.
How to reproduce:
$ configure --without-libserialport --without-libhidapi --without-libbluez
$ make
Capture does not stop for sample count values which exceed the range of
a 32bit type variable. Adjust the data type to 64bit.
How to reproduce: 8MSa/s * 600s -> 4,800,000,000 samples
$ sigrok-cli -d fx2lafw -o capture.sr --config samplerate=8M --time 600000
[ gsi: rephrased the commit message ]
Some FTDI chip based products ship with EEPROM content which makes
libftdi fail to lookup the USB strings, which breaks the scan for the
device's presence. The previous implementation was strict and only
accepted the absence of a serial number. This implementation also copes
when vendor and model cannot be gathered from the device, and provides
fallback values based on VID:PID numbers.
Also factor out a magic number for string lengths. Stick with dynamic
allocation since 3x 32bytes would be rather huge a local stack use, and
future maintenance might bump that string length again.
[ gsi: magic number in one spot, bounded string assignment, style nits ]
Submitted-By: Christo Crause <christo.crause@gmail.com>
Introduce a text to number conversion routine which supports non-decimal
bases and optional suffixes, but returns unsigned results and thus covers
a larger range of values. This kind of amends commit 97aa41e9b5 which
introduced the sr_atol_base() routine.
Check for the availability of the "no_reorder" linker attribute, which
keeps the list of builtin drivers in shape on LTO enabled build setups.
Keep backwards compatibility for platforms which lack support for the
"no_reorder" attribute. Phrase the implementation such that other
keywords as well as user provided external specs are possible.
This resolves bug #1433.
Submitted-By: Ivan Mironov <mironov.ivan@gmail.com>
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.
Gerhard Sittig
Frank Stettner
Soeren Apel
Helge Kruse
Petteri Aimonen
litospain
waka
Florian Ragwitz
Alberto Scotta
HReimann
Richard Allen
v1ne
Peter Skarpetis
Ralf
Niklas Thorne