Sven Schnelle [Tue, 14 Feb 2017 22:30:13 +0000 (23:30 +0100)]
Fix initial sample value for demo driver
devc->step is not reset on acquistion start, so acquisition
starts with a different value every time. Thats annoying when
using the demo driver to debug sigrok, so lets make sure that
it's reset to 0.
Marcus Comstedt [Wed, 1 Feb 2017 17:50:26 +0000 (18:50 +0100)]
Build: fix #865 yet again
It appears that the symmetry changes of setting CC and CFLAGS correctly
for C code compilation in commit 104f02f broke things for people using
some other version of setuptools which uses those vars instead of
CXX and CXXFLAGS when compiling C++ code. In order to make this work
everywhere, set _both_ sets of variables as required for C++ compilation.
No C code is compiled by the python binding module anyway.
Stefan Brüns [Fri, 13 Jan 2017 22:10:41 +0000 (23:10 +0100)]
scpi: Do not block when reading header of definite length blocks
When using SCPI over serial (over USB), we want the header without waiting
for the terminating newline, as otherwise the transfer may time out.
sr_scpi_get_data() will block until the message is complete.
Stefan Brüns [Sun, 8 Jan 2017 17:32:05 +0000 (18:32 +0100)]
scpi_serial: Get rid of intermediate buffer, do not strip newline
Lowlevel access functions should not alter the data. sr_scpi_get_string(),
which is called by most highlevel access functions, strips newlines
in a central place, and is only fed with data which contains newlines
as a final terminator.
IEEE 488.2 definite length blocks may contain arbitrary data, thus the
payload up to the provided length should be passed unaltered.
Track if the last received character is a newline, which can be used
by sr_scpi_get_string() and its callers to determine if the response
is complete.
Stefan Brüns [Thu, 12 Jan 2017 00:20:17 +0000 (01:20 +0100)]
scpi: Query current time just once, use microseconds for timeout
g_get_monotonic_time() returns current time in microseconds, use the same
granularity for storing the read timeout.
There is also no need to check the timeout if data has just been read.
Stefan Brüns [Sat, 14 Jan 2017 19:56:08 +0000 (20:56 +0100)]
yokogawa-dlm: Mostly fix dumping of current timebase
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
Stefan Brüns [Wed, 11 Jan 2017 23:29:03 +0000 (00:29 +0100)]
hameg_hmo: Mostly fix dumping of current timebase
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
Stefan Brüns [Sat, 14 Jan 2017 19:48:08 +0000 (20:48 +0100)]
strutil: Fix sr_period_string output
The output was wrong for all frequencies but 1 Hz, 1 kHz, 1 MHz and 1 GHz.
With this changes, the output may still be off due to rounding, but will
be correct as to the shown accuracy.
Gerhard Sittig [Fri, 30 Dec 2016 12:16:04 +0000 (13:16 +0100)]
scpi: Don't process received data of zero length
When nothing was received in a read attempt, we need not adjust the
buffered data's read position nor the glib string object's size. Skip
any processing for empty input, just keep checking for timeouts.
Gerhard Sittig [Sat, 7 Jan 2017 12:08:12 +0000 (13:08 +0100)]
scpi: Rephrase buffer resize for free space during SCPI read, add comments
Routine sr_scpi_get_data() checks for free space in the receive buffer,
and resizes the buffer when free space drops below a threshold. The
previous logic assumed that the resize and the read logic would interact
in some specific way to achieve the desired operation.
Adjust the buffer resize such that more free space is pre-allocated, yet
the payload size of the buffer is not affected. This eliminates the
dependency of the optional resize logic from subsequent activity for
reception of data that is non-optional.
Add comments while we are here, outline the steps taken in the
sr_scpi_get_data() routine.
Gerhard Sittig [Fri, 6 Jan 2017 21:00:28 +0000 (22:00 +0100)]
hameg-hmo: Rephrase the channel constraints check (analog vs digital)
Phrase the logic which checks the use of analog channels and digital
pods in more generic terms. Place a comment about the contraints' being
potentially dependent on the specific HMO model. This implementation
should lend itself better to future adjustment (HMO1002?).
Gerhard Sittig [Fri, 6 Jan 2017 19:53:50 +0000 (20:53 +0100)]
hameg-hmo: Map logic data from second digital pod to channels D8-D15
An internal libsigrok implementation detail prevents partial submission
of logic data for different channel groups in multiple calls. Instead
one logic packet needs to be sent in a single call, which combines data
for all channels.
Introduce a logic data storage which folds samples from several channel
groups that were received at different points in time into a combined
memory layout of larger unitsize. Stick with the former shortcut of
passing on the input bytes directly when only the first digital pod is
used during acquisition.
This change correctly maps data from the second pod to channels D8-D15.
Gerhard Sittig [Fri, 6 Jan 2017 17:56:40 +0000 (18:56 +0100)]
hameg-hmo: Do read from second digital pod during acquisition
The previous implementation only added one of the digital channels to
the list of enabled channels that are involved in the acquisition (the
first one that was found). This means that when the set of used digital
channels spans more than one pod/group, the second pod will never be
read from.
Make sure to enable one digital channel per pod/group, such that
acquisition will retrieve data from all involved input sources.
Add comments while we are here. Mention how the different setup, check,
start, and receive routines which are spread across several files do
interact to achieve acquisition.
Gerhard Sittig [Fri, 6 Jan 2017 17:12:55 +0000 (18:12 +0100)]
hameg-hmo: Send exactly one sigrok frame per scope frame
The previous implementation used to put FRAME_BEGIN and FRAME_END
markers around each received chunk of samples, while those chunks
correspond to a single channel (analog) or a group of eight channels
(digital) each. In other words, the hameg-hmo driver had provided a
multiple of the requested frames, and those frames were incomplete.
Make sure to only send FRAME_BEGIN before the first channel's data,
and FRAME_END after the last channel's data of a frame. Thus make
sigrok frames exactly match the scope's frames.
Add some comments on the frame marker and the acquisition stop logic
while we are here.
Gerhard Sittig [Fri, 30 Dec 2016 22:46:27 +0000 (23:46 +0100)]
hameg-hmo: Use the host's endianess to read analog channel data via SCPI
Configure the scope to the host's native endianess before downloading
acquisition data from analog channels. This unbreaks operation on those
models which default to a representation which differs from the host.
Gerhard Sittig [Sat, 7 Jan 2017 20:16:33 +0000 (21:16 +0100)]
Revert "scpi: Don't process received data of zero length"
Undo the change which skips management activities when no data was
received. This change breaks the current implementation, and needs to
get deferred until a delicate interaction between the resize and the
read logic has been eliminated.
Gerhard Sittig [Sat, 31 Dec 2016 13:25:07 +0000 (14:25 +0100)]
asyc-ii: Rephrase "exponent" logic when parsing packets
Replace a C library strcspn(3) call with the more portable glib
g_strstr_len(3) routine. This is possible since a single separator
is searched for, no actual "set of characters" is involved.
As a byproduct, this eliminates a "late" reference to 'cnt' at the
bottom of the routine, after the value was assigned in a rather distant
location at the top of the routine. The cost of strlen() should be
acceptable for a buffer with a single digit total length.
Gerhard Sittig [Sat, 31 Dec 2016 11:54:39 +0000 (12:54 +0100)]
asyc-ii: Prefer more portable and common string routines
Replace C language string operations with their glib incarnations for
improved portability. Prefer a common sigrok float conversion routine
over a DIY implementation.
Gerhard Sittig [Sat, 31 Dec 2016 11:48:59 +0000 (12:48 +0100)]
asyc-ii: Unobfuscate a comment on packet parse constraints
The specific packet layout puts constraints on the parse logic (case
sensitive comparison, order of comparison). Fix a comment that made no
sense before, and better reflect that there are two constraints.
Gerhard Sittig [Fri, 30 Dec 2016 12:27:29 +0000 (13:27 +0100)]
scpi: Rephrase length logic in data block reception, comment/group code
Slightly rephrase the SCPI code which parses the responses that carry
(binary) data blocks. Be explicit about NUL termination when parsing the
leading length spec in the response, obsoleting the array initializer.
Add lots of comments and group source code lines to better reflect
what's happening from the protocol's perspective.
Fix the returned error code in the path which reads responses of
excessive length in chunks. The previous implementation detected errors
but always returned code 0 (success).
Gerhard Sittig [Fri, 30 Dec 2016 12:16:04 +0000 (13:16 +0100)]
scpi: Don't process received data of zero length
When nothing was received in a read attempt, we need not adjust the
buffered data's read position nor the glib string object's size. Skip
any processing for empty input, just keep checking for timeouts.
Gerhard Sittig [Fri, 30 Dec 2016 12:11:59 +0000 (13:11 +0100)]
scpi: Minor style nits
Drop an initial assignment to a variable which never takes effect.
Add braces around the body of a more complex if block. Separate routines
from each other by exactly one empty line.
Gerhard Sittig [Fri, 30 Dec 2016 22:46:27 +0000 (23:46 +0100)]
hameg-hmo: Support BE format for SCPI sample downloads
When the channel state is retrieved, query the pre-set byteorder for
SCPI data blocks as well. When samples get retrieved during capture,
support float representations in either big or little endian format.
This commit unbreaks devices which operate in BE format by default
(tested with HMO2524). It keeps working with LE format as before. For
devices which don't support the byteorder query or return unknown
responses, LE format is assumed for backwards compatibility. The
device's byteorder is only queried and never set. This makes the
commit least intrusive.
Gerhard Sittig [Sun, 6 Nov 2016 11:30:09 +0000 (12:30 +0100)]
hameg-hmo: Declare support for 2 pods / 16 channels on HMO2524 and above
A comment mentioned that the models HMO2524 and above support 16 digital
channels (and thus have two pods for the probes). Move those models to a
section that declares the respective features, including trigger support
on the upper digital channels.
Model detection and reflection of supported channels was tested on HMO2524.
Gerhard Sittig [Sun, 6 Nov 2016 11:08:02 +0000 (12:08 +0100)]
hameg-hmo: Release enabled channels when acquisition start fails
Commit db81fbb58261 made sure to release a potentially previously
allocated list of enabled channels before (re-)building the list in the
current invocation of acquisition start.
This commit frees the memory in the error path near the failed creation
already, which reduces the period of time where unused resources are
held, and eliminates a memory leak when acquisition is not stopped after
failed start.
Both approaches can coexist. Freeing an empty list is perfectly fine.
Gerhard Sittig [Sun, 6 Nov 2016 10:51:08 +0000 (11:51 +0100)]
hameg-hmo: Fix index access for models with 2 pods / 16 digital channels
Fix the code which registers the name of the second pod for digital
probes. The previous implementation registered the first pod twice, and
lost the reference to the second pod. No harm was done, none of the
supported models declared support for two pods so far.
Factor out a channel to group mapping in the registration of digital
channels, while we are here.
Gerhard Sittig [Mon, 26 Dec 2016 12:12:35 +0000 (13:12 +0100)]
deree-de5000: rename to serial-lcr, update configure logic
The former DER EE DE-5000 driver was a very thin wrapper around the
ES51919 LCR meter chipset. None of its source was specific to the
deree-de5000 device. In fact it contained code for all currently
supported LCR meters, and it's expected that all LCR meters which
will get added in the future will fit in as well.
Follow the serial-dmm model. Rename the src/hardware/deree-de5000/
directory to serial-lcr/. Update the configure logic. Although the
source directory and the configure option are named serial-lcr, the
LCR meter still is used by specifying the "deree-de5000" device driver
(which just happens to reside in the serial-lcr driver sources, among
others).
Gerhard Sittig [Mon, 28 Nov 2016 00:01:15 +0000 (01:01 +0100)]
dmm: introduce support for ASYC-II 16-byte protocol in PRINT mode
Introduce an asycii.c source file (modelled after metex14.c) which
implements support for the 16-byte protocol of the ASYC-II multimeter
chipset (RX only, when the PRINT button was pressed).
Buildsystem wants CXX to be defined as $(CXX).
Otherwise it fallbacks to default value, which does not contain
"-std=c++11" statement.
Other changes (like CC=$(CC) and CFLAGS=$(CFLAGS) instead of CXX ones)
is not directly fix the issue, but fix cases, where CFLAGS (and CC)
differs from CXX* ones, so it could lead to similar errors in the future.
Gerhard Sittig [Sun, 6 Nov 2016 21:01:37 +0000 (22:01 +0100)]
deree-de5000: prepare to add more ES51919 based LCR meters
The "deree-de5000" driver is a very thin wrapper around the ES51919
chipset. We expect more models from other vendors to use that same
support code.
Model the registration of vendor/model combinations after the serial-dmm
approach. Register the DER EE DE-5000 device as the currently only
member in a list of drivers which all use the ES51919 chipset (no model
specific routines are registered in the absence of support for other LCR
meter chips).
This commit does not change the driver's behaviour nor the set of
supported hardware. It prepares the addition of more drivers in the
future.
Gerhard Sittig [Sat, 5 Nov 2016 17:01:43 +0000 (18:01 +0100)]
serial-dmm: comment nit on the UART bitrate for ES519xx chips
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.
Gerhard Sittig [Sat, 5 Nov 2016 15:19:58 +0000 (16:19 +0100)]
serial-dmm: sort the list of device drivers (part 1, bm25x)
The previous implementation seems to have added drivers in their "order
of appearance". Start sorting the rather long list, to simplify several
tasks: Add new entries as more drivers get written, find existing items
during research, identify and compare similar models during maintenance.
As a byproduct, there will be no doubt about where to put things during
future work :) and duplicates will be spotted immediately.
This commit puts 'bm25x' meters into one group. And comments on the sort
order and motivation for sorting the table.
Gerhard Sittig [Tue, 18 Oct 2016 18:35:23 +0000 (20:35 +0200)]
es51919 lcr: unbreak channel setup after successful detection
Commit 6bcb3ee8763bb introduced initial support for the Cyrustek ES51919
chipset. Its setup_channels() routine used to init a variable to assume
failure, then a loop added channels and changed the value to success.
Commit 5e23fcab889c6 changed channel setup to never fail, but kept the
initialization with an error code. Which prevented the operation of
successfully detected LCR meters.
Remove the no longer needed variable, instead always return success from
an operation which cannot fail.
Fixes: 5e23fcab889c6 "Simplify channel creation." Signed-off-by: Gerhard Sittig <redacted>
Gerhard Sittig [Sun, 16 Oct 2016 16:25:23 +0000 (18:25 +0200)]
output/ascii: add support for user configurable character set
Since tastes and requirements might differ, introduce support for a
user specified character set in the construction of ASCII art graphs
of signal levels. The syntax is "charset=<low><high>[<fall><rise>]",
the default remains backwards compatible with existing consumers.
In comparison to assuming a fixed character set, this change addresses
several distinct aspects:
Users can adjust the output for "higher visual contrast", or "straight
lines" instead of dotted patterns, or "increased difference in height"
for low and high signal levels, or "filled" (block like, "wall of text")
appearance of periods with high levels. User adjustable characters are
needed, as no single fixed set can satisfy the differing expectations.
Perception of the output heavily depends on specific terminals and fonts
in use.
Then there is the issue of levels versus edges, and how their timing
relates. By default edges are drawn at a point in time where the signal
was sampled and was deteremined to already _have_ changed and have
settled to the new level, which means that the position of edges in the
resulting graph might be off by up to one sample period. Strictly
speaking, the available set of samples only contains levels, and does
not hint where exactly an edge might have occured. Though this might be
considered rather nitpicky, representing the graph without edges does
better reflect the input data, and might simplify postprocessing.
Compare the previously only supported format (still the default, -O ascii):