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.
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.
Provide a common string helper routine which converts input text to a
double precision floating point number, and also gets its precision in
the process.
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.
Frank Stettner
Soeren Apel
Gerhard Sittig
Helge Kruse
Petteri Aimonen
litospain
waka
Florian Ragwitz
Alberto Scotta
HReimann
Richard Allen
v1ne
Peter Skarpetis
Ralf
Niklas Thorne