The hameg-hmo driver returns an incorrect sample rate: to reproduce this
bug, set the maximum sample rate from the ACQUIRE menu.
This patch fixes the driver so that the correct sample rate is returned.
During the initial configuration phase of the hameg-hmo driver
only send an OPC command if a SCPI command has been previously
sent to the device so that bogus SCPI timeouts are avoided.
The current starting index for the POD name is currently wrong as it is zero.
The official POD numbering starts instead at 1 (see device panel, buttons
and manual), so the current index used for message printing and groups
naming in the driver needs to be incremented by one.
Avoid double memory freeing leading to segmentation fault in when a SCPI
command fails to get a string due conditions such as a timeout or an invalid
command.
When setting the type of slope for the edge trigger function, also set the
trigger type to edge because it is not necessarily configured that way and
therefore such functionality might fail to work properly!
This fixes parts of bug #1328.
Update the Hameg/Rohde&Schwarz HMO driver (hameg-hmo) so that it
is possible to configure the logic threshold for digital signals.
The user can get or set the logic threshold configuration using
the channel group POD0 (and/or POD1 where available), for example:
sigrok-cli --driver hameg-hmo --get logic_threshold -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold=TTL --set -g POD0
sigrok-cli --driver hameg-hmo --get logic_threshold_custom -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold_custom=0.7 --set -g POD0
Update the default serial port options for Rohde&Schwarz and
Hameg mixed-signal oscilloscope devices connected through USB.
Also, remove misplaced and unused serial port configuration option.
This patch complements fa3d104f17
in terms of updating the USB PIDs for new devices (HMO series).
This fixes parts of bug #1321.
If no serial port option is specified on the command-line using the
"serialcomm" driver option, but the device is connected through USB
and it requires a known default serial port option, then use it in
order to avoid data corruption or even worse problems.
Note: the easiest way to reproduce data corruption on HMO3000 series
is to start an analog data acquisition (e.g. on channel CH1) after
switching from Ethernet mode to USB VCP mode (HO732 USB/Ethernet interface).
This fixes parts of bug #1321.
Correctly set the length of the buffer used to hold the SCPI response
from the device containing the binary acquisition data.
If a timeout occurs, truncate the buffer and send the partial response
from the device instead of getting stuck on timeouts!
Thanks to Stefan Brüns for reviewing the first version of this patch
and spotting out a serious problem with it.
This fixes bug #1323.
At the moment only the maximum number of frames to be acquired can be
configured for the Hameg/Rohde&Schwarz HMO mixed-signal oscilloscope
series driver (hameg-hmo).
This patch adds support to configure the number of samples to acquire
in both analog and digital (logic) mode.
This patch introduces the support for 16 digital (logic) channels for the
following oscilloscope models: HMO3032, HMO3042, HMO3052 and HMO3522
(previously only 8 digital channels were supported, i.e. only 1 POD).
This patch takes care of removing an invalid product model (HMO2522)
and adds a missing product model (HMO3522) in the hameg-hmo driver,
thus extending the number of supported oscilloscope models.
This fixes bug #1322.
The trigger range/mask "compression" procedure is apparently not
required and breaks triggering on a low line state.
This has been verified to fix the issue on a Hantek 4032L with FPGA
version 0x4303. It is possible that the procedure mentioned above
might be required for other FPGA versions, though that is unknown.
If you experience trigger issues with other FPGA versions, please
contact us for further debugging and testing.
This fixes bug #1402.
The Brymen BM86x supports up to two temperature probes. The dual display
can show individual temperatures of the two probes or differences. The
previous implementation "detected" a value of zero degrees when no probe
was attached and the display showed dash lines. When cycling assignments
of probes to displays, some valid combinations did not result in values
shown by the libsigrok driver.
An implementation detail of the formerly separate brymen-bm86x driver
was lost during recent migration of the dmm/bm86x parser into the
serial-dmm driver. When the meter's temperature function is selected,
it's essential to inspect the primary display's flags and digits, to
determine the secondary display's quantity and unit. Previous versions
never bothered to explicitly check for the "----" digits text, but the
combination of the primary's last digit showing C/F as well as the
binary C/F flags before the value provided hints which the secondary
displays group of digits and flags did not.
This fixes bug #1394.
When the list of all connections gets created which are supported by the
HID serial transport, items contain a "hid/ch9325/raw=/dev/hidraw3" path
and a "1a86:e008" pair of vendor and product IDs.
Separate the VID/PID pair by a period not a colon, so that --list-serial
output immediately becomes usable with "--driver <name>:conn=<spec>"
invocations. Eliminate the necessity to adjust clipboard context by the
user. This improves usability in cases where not a single connection
gets addressed, but a group of connections gets specified by ambiguous
conn= specs.
$ sigrok-cli -d uni-t-ut32x:conn=1a86.e008 --scan
Some meters require the reception of a request before they provide
acquisition data. Add support for the chip driver's .packet_request()
routine, and timeout handling in the serial-lcr driver. This follows
the serial-dmm model.
Allow LCR chip drivers to specify custom printf() formats for their
channel names. Default to "P1" etc in the absence of format specs.
This implementation is similar to serial-dmm.
The EEVBlog 121GW meter support always registers the three-displays
parse routine with the serial-dmm device driver. The single-display
routine need not be public. Adjust the visibility.
Reduce indentation for a continued line in a nearby declaration
while we are here.
Bug #1390 reports that "!desc" is always true (should be: false?). But
the actual problem would be that 'desc' is _not_ NULL when none of the
supported chips' VID:PID matched (FT232H happens to "get found" then,
erroneously).
Add a sentinel to the table of supported chips, such that 'desc' becomes
NULL upon mismatch, and the error path is entered.
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).
Remove the victor-dmm device driver. Its functionality is contained in
the Victor specific serial-over-HID transport, the FS9922 DMM parser,
and the serial-dmm device driver. The additional implementation became
obsolete.
Introduce a serial transport which undoes the Victor DMM cable's
obfuscation to the DMM chip's original data packet. Which allows to
re-use the existing FS9922 support code, obsoleting the victor-dmm
device driver.
This undoes the essence of commit bf700f679a, which introduced the
default conn= spec. Which improved usability: Users just select the
device and need not specify the connection. But also resulted in the
UT32x thermometer driver's probe to "succeed" as soon as the WCH CH9325
chip was found, no data check was involved in the scan. Unfortunately
this chip is also used in the popular UT-D04 cable, and thus there were
many false positives.
Remove the src/hardware/brymen-bm86x/ hierarchy of source files. Its
functionality has moved to the bm86x packet parser and the serial-dmm
device driver.
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.
The src/hardware/brymen-bm86x/ source code contains specific support for
the Brymen BM86x devices, and directly depends on the libusb library.
Rename the registered device (append the "-usb" suffix) before adding
BM86x support to the serial-dmm driver.
The Brymen BU-86X infrared adapters are sold with BM869s meters. Raw
streams of data bytes get communicated by means of HID reports with
report number 0 and up to 8 data bytes each. Communication parameters
are fixed and need no configuration.
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).
Keep the ES51919 chip support in the src/lcr/ directory, and move device
driver specific code to the src/hardware/serial-lcr/ directory. Implement
the same driver layout for LCR meters as is used for DMM devices.
This also addresses a few issues in the serial-lcr driver: Unbreak --get
and --show, do process a few LCR packets after probing the device, to
gather current parameter values. Keep sending meta packets when these
parameters change during acquisition, like the previous implementation
did. Use common code for frame/time limits.
Note that although LCR meters usually operate with AC to classify L/C/R
components, one of the officially supported modes is DC resistance.
Which means that an output frequency of 0 is not just a fallback when
packet parsing fails, it's also a regular value of the freq parameter.
List all supported frequencies including DC in strict numerical order.
Although all currently supported devices use the same ES51919 chip, the
implementation is prepared to support other devices which use different
LCR meter chips as well. The list of known equivalent circuit models and
output frequencies is kept in src/lcr/ chip support. It's assumed that
one LCR packet communicates the data for all channels/displays similar
to the serial-dmm driver implementation.
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 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.
The previous implementation provided a raw input stream of RX data from
read() calls to device drivers. This works great with genuine COM ports,
as well as with most setups which involve simple "cable expanders".
Recent additions of alternative transports (serial over HID and BLE)
added more protocol layers to the setup, and some device drivers are
reported to depend on the very framing of these transports: Mooshimeter
cares about individual BLE notification "frames", and the information
cannot get derived from the payload bytes. Some HID based cables which
obscure the DMM chips' serial protocol, or some HID based setups which
the serial layer does not abstract away as "a cable" may suffer from
similar requirements (do some drivers require access to individual HID
reports? Ikalogic? Victor DMM?).
Add support for an optional "RX chunk callback" which takes precedence
over "mere payload byte streams". Instead of returning payload bytes
from read() calls, the serial layer can call an application defined
routine and pass data bytes in the very framing which the physical
transport happens to use.
It's still up to the implementation of the specific transport whether
the callback approach is supported, and whether the wire's framing is
obeyed or whether payload data keeps getting provided as one raw stream.
It's also implementation dependent whether data reception transparently
occurs in background, or whether callers need to periodically "stimulate"
data reception by calling read or check routines which happen to call
back into the caller should RX data become available.
The approach that got implemented here is not universally applicable,
but serves those specific environments that were identified so far.
Introduce the serial_bt.c source file which implements the methods of a
serial transport and calls into the platform agnostic src/bt/ support
code.
Implement support for several chips and modules: RFCOMM (BT classic,
tested with HC-05), BLE122 (tested with 121GW), Nordic nRF51, and TI
CC254x (the latter untested). Read support is assumed to be complete,
write support for BLE may be incomplete due to lack of access to
hardware for tests.
Create a src/bt/ subdirectory for source files. Declare a platform
agnostic internal API for Bluetooth communication, and provide an
implementation of that portable API when the BlueZ library is available.
This implementation assumes that HAVE_BLUETOOTH and HAVE_LIBBLUEZ can be
used interchangeably, which is true for this initial version. When
support for other platforms gets added, the common and the specific
parts need to get sorted. Trying that now would involve guessing. :)
Adding Bluetooth communication is desirable for all sigrok supported
platforms. The BlueZ library is available on Linux which will receive
support first. Check for the BlueZ library's presence, determine a
HAVE_BLUETOOTH summary state, and extend the HAVE_SERIAL_COMM check.
Print version details for the external library.
This commit extends build support and version information, but does not
yet include the implementation of the serial transport primitives.
Register another driver for the UNI-T UT612 LCR meter, which is based on the
ES51919/ES51920 chipset, too. This device had been usable before when the
internal UART connection was made accessible (read: with a hack). It became
officially supported in unmodified form with the addition of transparent
serial over HID support for SiLabs CP2110 chips.
Switch the UT32x driver from running specific USB transfers to generic
serial communication. Preset the bitrate and frame format, but allow for
user specified overrides as well. Default to the WCH CH9325 HID chip,
but allow for overrides or more specific selection so that users can
resolve ambiguities with multiple cables.
The switch from libusb to hidapi removes a limitation that specifically
was reported for the Mac platform. The serial-over-HID variant should
now work as well. See bug #555.
Drop the background transfers. Stick with a local acquisition stop
routine, because a STOP request needs to get sent to the device. Reduce
the receive buffer size such that either blocking or non-blocking calls
will work. The additional flexibility of the buffer handling and packet
processing does not harm.
Do implement the transport methods for serial communication underneath
the common layer, by communicating HID requests and payload data by
means of HIDAPI library calls.
This commit adds the common logic of serial-over-HID communication and
implements the full internal serial transport API, including reception
in the background. But it does not yet support a single HID chip (which
each run their own proprietary protocol).
The implementation works with either hidapi-libusb or hidapi-hidraw
variant of the HIDAPI library, but was only tested on Linux.
Search for the optional HIDAPI library. Call the library's init and exit
routine, and print version information. Extend the common serial layer's
code paths for open, list, and find USB to also support serial over HID.
This commit prepares serial over HID, but the HIDAPI specific transport
for serial communication still is empty in this implementation.
Add a local RX buffer to the common code of libsigrok's serial layer.
Callers of the serial layer's API won't notice, this is an internal
detail of how alternative transports receive their data from the
physical line, and pass it to read() calls emitted by device drivers.
The libserialport specific code still calls into the library, and does
not use the RX buffer. Future HID and BLE support will use the buffer.
Add guards around the implementation of ES51919 chip support for LCR, as
well as modbus and SCPI over serial. To accept when the source files get
compiled in the absence of their dependencies, end up with an empty
implementation in that case.
This approach can simplify build rules when several optional external
dependencies result in differing sets of supported communication means.
Only reference the libserialport header when the library is available.
Allow to always compile the serial.c source file, but optionally end
up with an empty implementation. Make the sr_serial_dev_inst symbol
available outside of HAVE_SERIAL_COMM such that empty stub code can
compile. This prepares the introduction of alternative transports for
serial communication, while all of them remain optional.
The libsigrok serial layer internally uses parity and flow control
symbols which are provided by libserialport. Optionally locally declare
these symbols when libserialport is not available.
Introduce the HAVE_SERIAL_COMM identifier, which gets derived from, but
need not be identical to the HAVE_LIBSERIALPORT condition.
Derive the NEED_SERIAL automake condition from the general availability
of serial communication not the specific libserialport library.
Adjust source code references. Stick with HAVE_LIBSERIALPORT where the
specific library is meant, but switch to HAVE_SERIAL_COMM where the
availability of serial communication in general is meant.
Add an indirection between the common serial communication code and the
libserialport specific support code. Prepare the use of alternative
transports like USB HID in the future. Decide in the open() routine
which transport to use for subsequent operations (based on port names).
In theory only the transport specific layer depends on the libserialport
library's availability. In this implementation all support for serial
communication still depends on the HAVE_LIBSERIALPORT preprocessor
symbol. This needs to get addressed in later commits.
Eliminate a direct libserialport dependency in the OLS device driver.
Use libsigrok's internal serial layer's API instead to check for the
availability of receive data.
Add a serial_has_receive_data() routine to the serial layer's API which
returns the number of (known to be) available RX data bytes. Implement
support in the libserialport specific code.
Introduce a new serial_libsp.c source file, and move code from serial.c
there which is specific to libserialport. Keep the existing serial.c API
in place, this is a pure internal refactoring.
Adjust a little whitespace while we are here. Rearrange long lines to
keep related parameter groups adjacent (like pointer and size, or UART
frame length and flow control). Consistently reduce indentation of
continuation lines.
Store the most recent successfully applied set of parameters for serial
communication. Re-use these values as a fallback to calculate timeouts,
when the underlying transport fails to provide the current settings.
The rohde-schwarz-sme-0x device driver used to unconditionally reference
a libserialport header file. Remove that reference, it's not needed in
this specific driver.
Don't exit with an error if the FPGA is detected as unsupported.
Just issue a warning with the detected version and continue. I have such
a clone and it works with the original Saleae software and with sigrok
despite the fact that its FPGA version is 0xff.
Their commands are very similar to the U123x series, they just
add some more modes and the second channel. So use the re-functions
and just extend them where necessary.
Log reading not supported yet.
Basic testing done with a U1272A.
- fix the resolution of the CONF?-response:
the resolution is given with 6 decimal places
(instead of 8) like this:
VOLT +5.000000E+00,+1.000000E-04
- add more measurement modes that are possible with the meter:
CONT,COND,TEMP,PULS
It's important to remain aware that the serial layer's flush and drain
semantics differs from e.g. filesystem calls. The libserialport API is
said to follow the termios example.
Extend comments in the libsigrok API, to not depend on the libserialport
layer and the availability of its documentation. This raises awareness
during maintenance of sigrok device drivers, as well as the pending
addition of alternative transports for serial communication.
Adjust the doxygen comment for the read line routine while we are here.
Add "in" and "out" attributes for routine parameters.
The src/hardware/ subdirectory exclusively contains device drivers these
days, while common support code has moved to the src/dmm/, src/lcr/,
src/scale/, etc directories or src/ itself. Adjust comments in the
libsigrok-internal.h declaration blocks which reference source files.
Just allocate the memory needed to hold the very variable's size. No
need to duplicate the variable's type. Reduces redundancy and increases
robustness during maintenance.
Use g_malloc0() in sr_serial_new() to make sure all of the structure is
initialized.
src/hardware/sysclk-sla5032/protocol.c: In function ‘la_start_acquisition’:
src/hardware/sysclk-sla5032/protocol.c:244:8: warning: implicit declaration of function ‘max’ [-Wimplicit-function-declaration]
pre = max(pre, 2);
^~~
Without a measured quantity in packet.meaning->mq the C++ binding function
sigrok::Analog::mq() throws an exception and there is no way to check if
there is any measured quantity set in the analog package.
Add support for the Pepino-style of accessing >256K of memory. Because
this the only known extension of accessing >256K currently, we apply it
as soon as the sample size is bigger than 256K. Let's hope other
devices (if any) will follow this style. If not, we need to add support
depending on the device name later.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Magnus (creator of the Pipistrello) confirmed that he mixed up the
register names. The code was doing it correctly nonetheless but was
confusing to read because of this. Fix it to make it easier to
comprehend.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Let max_channels really carry the number of maximum channels the
hardware supports. We will handle the limitation of only half the
channels available in 200MHz mode later. Note that there won't be a
regression because we only set the variable but never check it. The
desired result of this patch is the removal of the NUM_CHANNELS macro.
The number of channels needs to be dealt with at runtime.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
We needs this twice so put it into a seperate function, so updates to it
will automatically handled for both callers.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
commit f51acd69 ("ols: combine demux samples") wrongly replaced the bit
pattern of 0x20 with the number of channels which just happens to be 32
as well. So, the code works but is confusing to read. Reword the
for-loop to make it more comprehensible.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The OLS protocol sends 16bit values to specify the sample count and
delay count. However, this 16bit value is the number of 32bit words to
be sampled, so the actual sample count is 4 times larger and does not
fit into a uint16_t. Extend it to support the full range of 256K
(LogicShrimp will need this) and to prepare support for devices with
even more memory (Pepino).
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The previous implementation assumed that a receive data chunk ends
exactly with a sensor packet's end. Yet the buffer had 32 bytes while
the packets have 19 bytes.
Separate the data reception from the packet processing. Collect whatever
chunks the USB connection provides, and scan the resulting buffer for
packets. Cope with either incomplete or corrupt or misaligned packets as
well as with multiple packets in receive chunks. The latter might happen
upon initial synchronization, when a device already sends data or the
serial port buffered previously communicated data.
In the regular case, the computer will process so fast that each single
character will be handled individually. We don't mind. The frequency is
some 60 times per second, and the data volume is 19 bytes. The software
works for the regular case, and synchronizes fast at startup or after
comm errors.
Always print the data bytes of received buffers in the packet parser,
then check some more fixed fields to not process invalid packets, then
process the packet content as the previous implementation did.
Call the packet parser for incomplete packets and discarded input
buffers as well (initial synchronization, re-sync after comm errors).
This results in the availability of more diagnostics during development.
Pass the packet's location and size from outside. This prepares the
logic to cope with situations where the receive buffer contains multiple
(potentially incomplete) packets.
Slightly unobfuscate the UT32x packet parser. The protocol is mostly
ASCII based, checks for hex numbers may be unexpected. Use symbolic
identifiers for the packet length and some special characters.
The previous implementation of the UT32x driver expected to see a conn=
spec, without it no device is found. Default to the USB identification
of the CH9325 chip, to make the driver work out of the box. Users still
can provide conn= specs and override the default for other cables.
Fill in the scan, open/close, get/set/list, acquisition start/stop logic
such that data acquisition with a PICkit2 works.
Trigger support needs more attention. User specified triggers either
seem to not take effect, or the trigger position is not in the expected
location. It's yet to get determined what's the issue.
This implementation is based on protocol information gathered from the
pk2-la project.
Remove a free() call in an error path for a list which immediately
before the call was determined to be NULL. Use index 0 and 1 for
channels P1 and P2 respectively (the previous implementation used 0
for both channels).
The current implementation of the SCPI DMM driver is conservative about
checking the device's being operational, but the *OPC? queries are found
in unfortunate locations. Run the OPC query right before running the
next "actual" command, not afterwards. And certainly not between sending
requests and potentially gathering responses in subsequent calls.
This commit does not change current behaviour, but improves maintenance
before pending commits.
The "get MQ" helper routine communicates SCPI responses and translates
them to internal "MQ and flag" values. Optionally return the MQ table
entry reference to callers, so they don't have to repeat the table
lookup when the function's default precision is required, or should
future "start acquisition" requests need to refer to the meter's current
function.
Supported SCPI DMM devices will differ in the set of options and whether
parameters can get queried or configured. Use a "generic" set of devopts
during scan and for simpler models, prepare support for other sets of
devopts for more complex models.
Implement the scpi-dmm driver in such a generic way that it could work
with several protocol variants and with differing models which happen to
use any of these protocol variants. Prepare a list of supported models
with their respective SCPI command set, set of DMM functions and their
precision.
Add support for Agilent 34405A. The ten functions of this device got
tested and are operational, in continuous mode as well as with sample
count or capture time limits. The driver can query the current meter's
function, can change the function, and can run acquisitions in either
the current mode or with a user specified function selection. There is
some potential for improvement: AUTO/MIN/MAX/HOLD indicators are not
supported by this implementation.
The SCPI protocol may communicate strings in quoted form, enclosed by a
matching pair of single or double quote characters, and occurances of
this very quote character within the string get doubled (escaped). Add a
common routine to undo the quotes.
Free the SCPI hardware info after successful model detection, too. Only
allocate the device instance when a supported model was found. Link the
device context earlier right after allocation, for easier verification.
The Fluke 45 probe routine tries to detect whether the serial port is
"in echo mode" (which already is questionable before the IDN query).
In the absence of a response, the library segfaults. Fix it.
Align the scaling items such that all numbers are aligned. Drop unneeded
"prefixes" for the 2nd display's tables, the main and sub displays already
have their individual tables which reside in their respective groups.
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.
Introduce the dmm/eev121gw.c source file with parse routines for the
EEVblog 121GW meter's 19-bytes binary packets. Get the values and MQ
properties of the device's several displays (main, sub, bar) in several
individual parse calls.
This commit introduces initial support for the device. Some of the modes
and features are untested, as are some of the device's ranges.
Due to some SCPI command changes that Siglent made, the connection
failed due to the wrong commands being send to the device.
This might fix parts of bug #1242, though initial tests show that
further changes might be needed.
[Note: This commit consists of multiple squashed commits from
marchelh <marchelh@gmail.com> and various fixups and rebasing
operations by Uwe Hermann <uwe@hermann-uwe.de>]
Regular operation of serial DMM drivers optionally can dump packet bytes
after the intialization phase has synchronized to the stream. Failure to
synchronize to the stream left developers without a dump, which complicates
research what went wrong.
Do dump packet content while the serial_stream_detect() routine tries to
synchronize to the stream. Use the spew level since the dump occurs upon
every attempt, which translates to: every received byte until a valid
packet was seen (or the synchronization phase expired).
The previous implementation always dumped 23 data bytes for received
packets. This could result in truncated diagnostics information, and/or
access to invalid buffer content.
Rephrase the packet dump routine such that the specific meter's exact
packet length gets dumped, and use the common hex dump support code.
Introduce common support for hex dumps in the string util collection.
There are explicit allocation and release routines for the textual
representation of the data bytes, so that callers are free to chose
whether and how to decorate the dump and where to send the message.
Keep (part of) previous results around when the VCD input module gets
reset, and check the header of the next import against previous runs to
avoid issues in applications. This addresses the VCD specific part of
bug #1241, and resolves the remaining part of bug #1306.
Applications are not prepared to handle changes in the channel list
between multiple acquisitions from the same source (device drivers
or input modules). Introduce common helpers to compare channels and
channel lists.
There was the sr_channel_new() allocation routine, but releasing that
allocation was open-coded in call sites. Add the sr_channel_free()
routine for code re-use and consistency.
This addresses part of bug #1306. The reset() method of the VCD input
module was incomplete, and did not process new data upon second read.
Improve robustness and add missing reset instructions. Void invalid
pointers and avoid NULL dereferences in cleanup paths.
Example:
In file included from src/hardware/kecheng-kc-330b/protocol.h:26,
from src/hardware/kecheng-kc-330b/api.c:22:
src/hardware/kecheng-kc-330b/api.c: In function ‘config_list’:
src/libsigrok-internal.h:51:34: warning: division ‘sizeof (void *) / sizeof (void)’ does not compute the number of array elements [-Wsizeof-pointer-div]
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
^
src/libsigrok-internal.h:55:32: note: in expansion of macro ‘ARRAY_SIZE’
#define ARRAY_AND_SIZE(a) (a), ARRAY_SIZE(a)
^~~~~~~~~~
src/libsigrok-internal.h:964:43: note: in expansion of macro ‘ARRAY_AND_SIZE’
std_opts_config_list(key, data, sdi, cg, ARRAY_AND_SIZE(scanopts), \
^~~~~~~~~~~~~~
src/hardware/kecheng-kc-330b/api.c:296:10: note: in expansion of macro ‘STD_CONFIG_LIST’
return STD_CONFIG_LIST(key, data, sdi, cg, NULL, drvopts, devopts);
^~~~~~~~~~~~~~~
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).
There are code paths where dev_close() tries to access a USB handle
which does not exist. This was observed with this command:
$ sigrok-cli -d brymen-bm86x --scan
On Windows, this device can either enumerate as 04b4:602a or 04b5:602a,
depending on which vendor driver is currently being used, so we have to
support both in the hantek-6xxx driver as well.
This fixes bug #1295.
In the case where the input unit was not in the array, the for loop would
complete, but the following test would then read past the end of the array
since 'i' would already have been incremented to the array size.
Spotted because unitless data was getting SI prefixes with no unit, though
this would not have been deterministically reproducible.
This fixes parts of bug #950.
The comment says "A requested value is certainly on the way", but the code no
longer works this way. The receive handler requests a value and blocks until
it is received. There is no value pending between receive handler calls, so
this code now only leads to a timeout.
Applications might pass NULL for the buffer, and input modules might
accept it (or just cope). Eliminate a potential NULL dereference in
the emission of diagnostics messages.
On Windows, this device can either enumerate as 04b4:6022 or 04b5:6022,
depending on which vendor driver is currently being used, so we have to
support both in the hantek-6xxx driver as well.
This fixes bug #918.
This is happening because the send() and recv() functions
have different prototypes on POSIX and Windows. Using the casts
is required on Windows and doesn't hurt on POSIX systems.
[...]/protocol.c: In function 'tcp_send':
[...]/protocol.c:161:26: warning: pointer targets in passing argument 2 of 'send' differ in signedness [-Wpointer-sign]
out = send(tcp->socket, buf, len, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:997:34: note: expected 'const char *' but argument is of type 'const uint8_t * {aka const unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI send(SOCKET s,const char *buf,int len,int flags);
^
[...]/protocol.c: In function 'ipdbg_la_tcp_receive':
[...]/protocol.c:201:32: warning: pointer targets in passing argument 2 of 'recv' differ in signedness [-Wpointer-sign]
int len = recv(tcp->socket, buf, 1, 0);
^
In file included from [...]/protocol.c:24:0:
[...]/include/winsock2.h:992:34: note: expected 'char *' but argument is of type 'uint8_t * {aka unsigned char *}'
WINSOCK_API_LINKAGE int WSAAPI recv(SOCKET s,char *buf,int len,int flags);
^
[...]/protocol.c: In function 'data_available':
[...]/protocol.c:73:38: error: 'bytes_available' undeclared (first use in this function)
ioctlsocket(tcp->socket, FIONREAD, &bytes_available);
^
[...]/protocol.c:73:38: note: each undeclared identifier is reported only once for each function it appears in
[...]/protocol.c:84:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
The fx2lafw(4) driver supports mere logic analyzers as well as mixed
signal devices, but does not support channel group specific device
options. Avoid an error message when channel group device options get
queried, the condition is perfectly legal and non-fatal.
How to reproduce:
$ pulseview -d fx2lafw
$ sigrok-cli -d fx2lafw -g Logic --show
This fixes bug #1267.
The "firmware load failed" message would be even more helpful if users
could learn which firmware file failed to load. Add those filenames to
various FX2-based drivers.
This addresses bug #1262.
As per Daniel Anselmi <danselmi@gmx.ch> in an email conversation, the
code was actually written by Eva Kissling <eva.kissling@bluewin.ch>
(as indicated in the commit logs as well). Fix the headers accordingly.
Use "ipdbg-la" everywhere to refer to the driver, including
in function name prefixes etc. There's no need to encode
website details (.org) into the driver/function name(s).
With gcc 8 this yielded:
src/input/wav.c: In function ‘receive’:
src/input/wav.c:345:51: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Wformat-truncation=]
snprintf(channelname, sizeof(channelname), "CH%d", i + 1);
^~
src/input/wav.c:345:48: note: directive argument in the range [1, 2147483647]
snprintf(channelname, sizeof(channelname), "CH%d", i + 1);
^~~~~~
src/input/wav.c:345:5: note: ‘snprintf’ output between 4 and 13 bytes into a destination of size 8
snprintf(channelname, sizeof(channelname), "CH%d", i + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The previous implementation accepted either empty integer or empty
fractional parts of a floating point number, but also when both parts
were missing ("." input). Insist in at least one of the parts to be
present.
Programmatic output of floating point numbers might choose to print
spaces instead of an explicit '+' sign, to align the output with the
result of formatting negative numbers yet achieve a screen appearance
similar to what humans would have written. Skip leading whitespace
before insisting in seeing either signs or digits or decimals.
Accept numbers like "123." where the period (dot) is present yet the
fractional part is empty. Adding a period but no additional digits is a
popular method of turning an otherwise integer literal into a float.
Compilers and strtod() routines accept this notation, too, so we have to
expect seeing such input.
The VCD specification requests that timestamps will strictly increase as
one advances through the file. Add another check where the previous
implementation resulted in a tight loop and made the application stall.
Do print an error message and abort file processing in that case.
This fixes bug #1250.
Adjust the calculation of the '^' marker's position in T: lines of the
-O ascii/bits/hex output modules such that it matches the sample data
lines' layout. Add comments which discuss the motivation of the marker
position's calculation, which differs among each of those modules.
Strictly speaking -O bits was already correct. But I chose to adjust and
comment the logic such that multiple output modules follow a common
pattern. If performance is an issue, the bits.c change might be worth
reverting.
This commit fixes bug #1238.
- add support for multiple transfers.
- set nummber of samples to 1 for FPGA FW version 0
- increase size of data transfer buffer to 2kB.
Signed-off-by: Andrej Valek <andy@skyrain.eu>
Callback for data transfer is separated from status. This change will be
used for better data transfer sending/receiving. Cast signal, that trigger
has been captured was moved into state: H4032L_STATUS_FIRST_TRANSFER.
Signed-off-by: Andrej Valek <andy@skyrain.eu>
- get FPGA version in dev_open
- enable some features only for newer FPGA
- decrease printing number of message of FPGA version
Signed-off-by: Andrej Valek <andy@skyrain.eu>
Split the creation of channels and groups as well as the creation of the
session feed buffer into separate routines. Re-allocate the buffer after
reset but do not re-create the channels and groups.
This implementation assumes that after reset() of the input module, the
very same set of channels (including their order, names and enabled
state, as well as group membership) results from processing the
subsequently fed file content. Reading rather different configurations
from the same input file by means of repeated reset and re-read may not
work as expected.
Explicitly check GString pointers for validity before calling glib
routines that would access string content. This silences an assertion
error for a non-fatal runtime condition:
(process:17044): GLib-CRITICAL **: g_string_free: assertion 'string != NULL' failed
Rephrase common input reset logic such that additional common code can
execute after the individual module's reset callback. No behaviour has
changed, the module's reset callback still is optional, and identical
log output gets emitted.
Do clear the sdi_ready flag in the common sr_input_reset() routine, so
that all input modules will parse header information again before
processing sample data when subsequent calls receive new file content.
Void the input module's receive() buffer from common reset code. This
unbreaks the feature of re-reading previously consumed input files.
Extend comments in the common reset and free code paths, which involve
the modules' reset and cleanup routines, which interact in non-trivial
ways. Discuss the responsibilities of common and individual routines, to
remain aware during maintenance.
Acquisition won't work correctly in a multi-threaded environment, when
config_set() and config_get() are called with a channel group.
The channel switching itself has moved to scpi/scpi.c, to be able to
handle switching in a thread safe way.
Use of the thread safe SCPI functions, so no write+read operation is
interruped.
Also return float values instead of double value in acquisition mode.
This is related to bug #779.
This ensures that SCPI read/write/write+read operations are thread safe.
F.e.: If a write operation expects a return value (in other words: a
read operation), it is not allowed to be interrupted by another write
operation.
To simplify things, the SCPI helper functions are moved from
scpi/helpers.c to scpi/scpi.c and also are renamed to fit the naming
scheme.
libgpib in particular will abort the program execution in case of
concurrent operations.
The chronovu_la8 input module is capable of handling either file type,
generated by LA8 or LA16 vendor software. Automatic detection is not
available, but user provided channel counts work fine.
Adjust the input module's name and description, and claim support for
.kdt as well as .kd1 files.
Add developer notes on implementation details, the file content's
constraints, and potential future adjustment.
The file format is funny, a data part is leading (fixed size) and a
"header" part follows. The previous implementation sent the header part
to the session, too, pretending it was part of the data. This change
limits the number of samples that get sent to the session.
Comment on the file layout and header fields while we are here. This
information got lost in commit 02e24c0ce0 when the input module got
converted from do-it-yourself file operations to having intrinsic
handler routines invoked from common logic which handles the file.
Prefer the more portable UINT64_C() macro over the UL suffix when a
literal needs to span "more than 31 bit positions". Adjust other
locations for consistency across the source file.
Commit 8c4bff1d25 introduced a routine which prints what mostly should
be text, and avoids non-printable characters. This implementation used an
incorrect format string, which could result in data getting written past
the end of a buffer. Fix the format string.
src/hwdriver.c: In function ‘log_key’:
src/hwdriver.c:648:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
opstr = op == SR_CONF_GET ? "get" : op == SR_CONF_SET ? "set" : "list";
^~
src/hwdriver.c: In function ‘check_key’:
src/hwdriver.c:681:13: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
opstr = op == SR_CONF_GET ? "get" : op == SR_CONF_SET ? "set" : "list";
^~
src/hardware/siglent-sds/api.c:596:3: warning: Argument to g_free() is the address of a global variable, which is not memory allocated by malloc()
g_free(cmd);
^~~~~~~~~~~
src/hardware/siglent-sds/api.c:641:3: warning: Argument to g_free() is the address of a global variable, which is not memory allocated by malloc()
g_free(cmd);
^~~~~~~~~~~
Reported by scan-build:
src/hardware/lecroy-xstream/protocol.c:680:12: warning: Potential leak of memory pointed to by 'analog.data'
return SR_ERR;
^~~~~~
Reported by scan-build:
src/input/logicport.c:1186:18: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
.format_match = format_match,
^~~~~~~~~~~~
Log determined header format when parsing trace32 file headers. Keep
another log message during regular processing, but silence it during
format match.
Use more appropriate data types for local and instance variables. Adjust
format strings accordingly.
There were several issues with the previous implementation of the logic
which parses trace32 input files: A string comparison was inverted, and
compared a seven character literal to a five character copy of the input.
One more character was trimmed before CTRL-Z (the CP/M EOF), which often
is SPACE in input files, but might be excessive on other input files.
Replace a DIY character search while we are here. Use symbolic names for
special characters. Factor out a test and memory release, to simplify
error code paths in the remaining logic. Extend comments.
There is not much point in log messages about format mismatch in the
auto detect phase, where each module gets queried in turn and most are
supposed to not match.
Do not print non-printable characters in log messages. Those could occur
in the format detection phase, or in the regular processing of input
files that either are unexpected or invalid (or is there a binary header
format variant even?).
Although the file format handled by this input module appears to be of
fixed size (8MiB plus 5 more bytes), it's more reliable to use a data
type for the file size that is larger than "an int". Although off_t
would be most portable, use uint64_t to match the code which passes the
parameter to the input module.
The previous implementation already was inconsistent (used to allocate
255 bytes and claimed that 128 bytes were sufficient). While existing
formats already required more than a few bytes of input (regular VCD
files' header sections exceed 255 bytes length).
Increase the buffer size that gets passed to input modules' match
method. Use 4MiB for consistency with other locations. Do not enforce a
minimum size, as there are valid input files which are shorter than 128
bytes. Auto-detection failed on those.
This addresses part of bug #1200.
When users don't specify the input format, applications can try to have
the format auto-detected. Some of the tests were weak and could result
in false positives.
Add a 'confidence' parameter to the input modules' format_match()
method. Claim high confidence (1) for those formats which can check
magic strings or the presence of essential keywords (vcd, wav). Claim
medium confidence (10) for those formats which happened to mis-detect
inputs in the past (trace32_ad). Claim weak confidence (100) for those
formats which totally lack reliable conditions and rather guess than
detect (chronovu_la8).
Prefer the best match in public scan routines. Return at most one module
to callers even if multiple modules matched, to keep the current API.
This addresses part of bug #1200.
Implement an input module for .lpf files, the "LogicPort File" format of
the Intronix LA1034 vendor software. This version supports wires with
enabled and inverted state, compressed samples, signal names, signal
groups (but not multiple assignment), and automatic format detection.
The logic which determines whether "the file header" was completely
received, and sample data can get sent to the session, implements an
assumption in the absence of a better and more reliable condition.
Invalid input gets rejected, but diagnostics is rather limited. Since
all channels get to be the member of a channel group, either specified
by the user in the input file, or arranged for in the input module, the
"missing separator" part of bug 1186 has become obsolete.
src/analog.c:205:23: warning: declaration of ‘i’ shadows a previous local [-Wshadow]
for (unsigned int i = 0; i < count; i++) {
^
src/analog.c:178:18: note: shadowed declaration is here
unsigned int b, i, count;
^
[...]
src/analog.c: In function ‘sr_analog_to_float’:
src/analog.c:194:9: warning: declaration of ‘offset’ shadows a previous local [-Wshadow]
float offset = analog->encoding->offset.p / (float)analog->encoding->offset.q;
^~~~~~
src/analog.c:177:8: note: shadowed declaration is here
float offset;
^~~~~~
Allow developers to specify the (default) number of frames at compile
time (default to "off" as before). Accept the frame limit spec at scan()
time as well. This is useful when applications don't run config_set() at
runtime.
Tested with:
$ pulseview -d demo:logic_channels=0:analog_channels=1:limit_frames=4
The previous implementation supported the generation of frames as a
compile time option. This change lets users adjust the feature at
runtime.
In the absence of a frame count limit no frame begin/end markers get
sent (the default behaviour of the previous implementation). When a
frame count limit is specified, the respective number of frames gets
sent and acquisition stops.
The fixed amount of 1000 samples per frame is an arbitrary choice. This
compile time option is easily adjusted in the source code.
Introduce support for the "graycode" logic pattern. Generate up to
64 bits of graycode output (all logic lines, no repetition, not limited
by the generator's internal pattern buffer). The implementation was
tested with 16 channels.
Keep a context variable around with a bit mask for all logic channels.
This is convenient in setup and generation routines, to avoid garbage
in unassigned bit positions of session feed packets.
Move the declaration of codes for pattern types before the declaration
of the context container such that the latter can reference the former.
Add 'int' to an unsigned variable that omitted the base type.
When auto-detection tries to find the input module that can handle a
file, unexpected input format should be considered non-fatal. Only emit
error messages when process_header() got invoked from process_buffer()
after initialization. Emit debug messages in early stages where no input
module context exists yet.
The initial voltage threshold in dev_open() was being set to a
default value in the devc->cur_threshold variable but not actually set
in the device itself.
Patch by Jörg Alpers <jalpers@gmx.net>, thanks a lot!
- fix LIBUSB_TIMEOUT errors
- fix same data receiving
- send reset vendor request before new data getting
- decrease USB polling timeout
This fixes bug #1190.
Signed-off-by: Andrej Valek <andy@skyrain.eu>
- use pragma to handle different behavior between gcc and minGW bit-field packing
- bit-field integer variables needs to be align to 2-byte boundary
Compiler does not produce an error when accessing into non-__packed pointer.
However, the field might not be properly aligned for this type.
More information could be found on:
- https://sourceforge.net/p/mingw-w64/bugs/275/
- http://www.keil.com/support/man/docs/ARMCC/armcc_chr1359124990875.htm
Signed-off-by: Andrej Valek <andy@skyrain.eu>
Before this change, the loglevel check would only be performed for the
default log handler in libsigrok, but not for other handlers set
via sr_log_callback_set().
This fixes bug #698.
A local buffer was too small, snprintf() was used to write the
name of the analog-1-1-xxx ZIP archive names in that buffer.
Due to the limited size, only 3 characters were usable for the last
number component, i.e. the code would loop around from analog-1-1-999
to analog-1-1-100 (instead of analog-1-1-1000).
As a quickfix, increase the buffer size by a large margin, a nicer
fix should be used later on.
These trigger quite often with unrelated devices and confuse people.
scpi_usbtmc: Failed to get configuration descriptor: LIBUSB_ERROR_NOT_FOUND, ignoring device.
The Modbus RTU implementation was inappropriately returning lengths
from the serial functions when the calling functions expect only an
sr_error_code value.
Make sure to not exceed the ctx->analog_samples[] array bounds. Don't
use the (huge) channel's index in the device's(!) channel list, instead
use the zero-based and dense index into the array of analog samples in
the accumulation buffer, before writing to the external file.
This fixes the segfault reported in bug #1124.
The process_analog() logic is rather complex, dealing with the total
list of channels in the device (which can be of different types), and a
number of submitted samples for a specified list of channels. Replace
the rather short variable names for i, j, c (and num_channels) with
something longer that hopefully increases readability of the complex
loop bodies.
Note that this change merely renames identifiers, and does not change
behaviour.
Instead of nesting indentation levels upon equality of a value, skip
iterations upon inequality. This reduces indentation, and might improve
readability.
[ Indentation changes, see 'diff -w -b' for the essence. ]
Use serial_readline in acquisition mode, otherwise data from the
Re:load Pro could get lost.
Use reloadpro_receive_data() for all commands when in acquisition
mode. When not using a single point of receiving data, data could get
lost.
Prefer sigrok's endianess conversion helper over the inet htons()
routine which is harder to read (is "network order" little or big?).
Writing the conversion results in units of bytes also avoids misaligned
memory access. The header length is odd, each payload item got written
as an uint16_t item to an odd address.
Guido Trentalancia
Uwe Hermann
Nadav Mavor
Mike Walters
Gerhard Sittig
Daniel Anselmi
Andreas Piesk
Vitaliy Vorobyov
Gerd v. Egidy
Dewelde Anthony
Frank Stettner
Soeren Apel
Thomas Andres
Michael Klengel
Wolfram Sang
Martin Ling
majekw
Mike Williams
Paul
Michał Janiszewski
luftek
Thomas Weißschuh
marchelh
Peetz0r
Andrej Valek
Eva Kissling
Valentin Ochs
Matthias Schulz
Adrian Stratulat
Joerg Alpers
JohnCh
Bastian Schmitz
Sergey Alirzaev
Mandl
Sven Bursch-Osewold
James Churchill
Axel Hinrichs
Romain Tartière