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 ]
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).
Rephrase the logic which turns HIDAPI paths returned from enumerations
into something that can be used with conn= device options. Rearrange
code paths and rename variables to hopefully increase readability, and
to prepare support for more conditions in future implementations.
Replace the "IOService:" prefix on recent Mac versions with the "iokit="
literal, to eliminate the previously unhandled colon in path names. This
resolves bug #1586.
Move the allocation of a writable buffer from the callers to the callee,
to simplify multiple call sites, and most of all because the caller need
not be aware of the buffer's required size (input and output size can
differ in either direction).
Update the conn=hid/ section in README.devices, add the iokit= prefix.
Extend the previously introduced skeleton driver for UNI-T UT181A. Introduce
support for the full multimeter's protocol as it was documented by the ut181a
project. Which covers the retrieval of live readings, saved measurements, and
recordings, in all of the meter's modes and including relative, min/max, and
peak submodes. This implementation also parses compare mode (limits check)
responses, although it cannot express the result in terms of the session feed.
Announce the device as a multimeter as well as a thermometer, it supports
up to two probes including difference mode. When in doubt, prefer usability
over feature coverage (the driver side reflects all properties of the meter,
but not all features can get controlled by the driver). The probe routine
requires that users specify the serial port, and enable serial communication
on the meter.
Several TODO items remain. Comments in the driver code discuss limitations
of the current implementation, as well as cases where the meter's features
don't map well to sigrok's internal presentation. This implementation also
contains (optional, off by default) diagnostics for research on the serial
protocol.
This adds support for the Mooshim Engineering BLE based Mooshimeter.
Because the meter requires raw BLE packets, the driver uses the BLE
layer directly. Since the meter has no physical way of configuring it,
the actual configuration is set entirely with sigrok device options.
Add more examples of conn= specs for HID and Bluetooth devices to the
section which discusses COM ports. Outline the formal syntax and its
optional fields. Discuss how colons in device addresses interfere with
"-d <drv>:conn=<spec>" environments.
Slightly rephrase README.devices since there is no strict distinction
into "fully automatic" and "always manual". Some drivers _accept_ conn=
specs when provided, _and_ support automatic detection of enumerable
devices, _and_ might implement defaults but also support overrides.
Nit, numerically sort the list of Uni-T cables (which is about to grow
in the future) for improved readability.
Add two more devices which require users to manually enable the serial
communication (Brymen BM257s, EEVBlog 121GW).
The conn= specification is not strictly related to RS232 communication.
Provide examples for other USB specs (as they are used for some DMM and
LCR drivers), as well as TCP and VXI (which are often found with MSO
drivers).
Remove vague statements from the README. On all current distributions,
the udev paths are identical, anyone deliberately deviating from the
defaults should be able to handle it by themselves.
Rules in /etc/udev/rules.d/ should only be used for customization, or
for locally built packages.
This driver is neither working nor has it been in a compiling state for
a long time, so unhook it from the build until it is fixed and works.
The files (api.c and protocol.[ch]) are still in git, but won't end up in
released tarballs and they don't get built (neither git nor tarballs).
This also allows us to drop the otherwise unneeded dependency on libudev.
When the MSO-19 driver comes back, it should be in a form that doesn't
require the inherently Linux-only libudev anyway. See also:
http://sigrok.org/bugzilla/show_bug.cgi?id=65
Gerhard Sittig
Timo Kokkonen
Uwe Hermann
Derek Hageman
Stefan Brüns
Soeren Apel
magnuskarlsson
Aurelien Jacobs
Matthias Heidbrink
Matthias Heidbrink
Martin Ling