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):
Uwe Hermann [Wed, 12 Oct 2016 20:33:19 +0000 (22:33 +0200)]
hantek-6xxx: Update driver to use the USB product version field.
We now require the use of the latest fx2lafw firmware which uses the
same USB VID/PID (1D50:608E) for the Hantek 6022BE and the variants
and rebadges of that device (e.g. the SainSmart DDS120).
The variants can be distinguished via the USB product version field.
This allows much faster and configurable sampling rate, and faster
reaction to function switch.
This also gives a more repeatable job ordering and more reliable
query/reply association.
Gerhard Sittig [Sun, 16 Oct 2016 16:25:22 +0000 (18:25 +0200)]
tests: relax the "version text" length check, accept longer strings
The version text length check fails for git setups that use more digits
in abbreviated hashes, as is recommended by e.g. the Linux kernel project.
Raise the upper limit for acceptable version strings, and add comments
on how the limits were determined. The test still might fail in setups
of slightly different configuration, but now it's easier to see why the
test failed, and how to adjust the test.
Gerhard Sittig [Sun, 16 Oct 2016 16:25:21 +0000 (18:25 +0200)]
asix-sigma: fix buffer length check in register write helper
Fix the array size check in the sigma_write_register() routine. The
'len' parameter specifies the number of bytes to write, while the 'buf'
array holds one nibble per array item.
The previous implementation (commit e8686e3ae36c1) switched to a
constant size and made the buffer large enough so that no existing
request would exceed the buffer, fixing an overflow that was present
before that commit. But the most recent size check was incomplete and
might erroneously succeed for larger amounts of write data.
It's assumed that the issue which gets addressed here never occured in
practice. The constant-size buffer could hold up to 39 bytes of input
data in their transport representation, while the largest data that was
passed to the write routine is six bytes (trigger LUT params).
Fixes: e8686e3ae36c1 "asix-sigma: Avoid use of variable length arrays" Signed-off-by: Gerhard Sittig <redacted>
Gerhard Sittig [Sun, 16 Oct 2016 16:25:20 +0000 (18:25 +0200)]
asix-sigma: store "limit samples" value, re-determine "limit msecs" period
The driver internally implements the "limit samples" feature by means of
the "limit sample period" approach. Determination of the corresponding
period of time for captures depends on the sample rate as well as the
maximum sample count, and thus needs to be re-done when either setting
changes.
Introduce a "limit_samples" variable so that the value is available when
needed later. As a byproduct the parameter can be retrieved now (get).
Add comments to the sigma_set_samplerate() routine's sections, since
quite a bit is happening there, and interacts with other locations.
Gerhard Sittig [Sun, 16 Oct 2016 16:25:19 +0000 (18:25 +0200)]
asix-sigma: fix out-of-range access to the samplerates[] array
Commit 2c9c0df86eaf removed the sentinel from the samplerates[] array,
but did not adjust the test which checked whether a rate is listed in
the set of supported rates. This could result in an out-of-range access
beyond the array's last item.
Fix the "listed?" check after iterating the table of supported rates.
Cope with either presence or absence of a sentinel in the array.
Address some more style nits while we are here. Rename an identifier
for a local variable which unintentionally might suggest that it would
be a preprocessor macro (all-caps). Reduce redundancy in data type
references as well as in the determination of the array size.
Mike Meyer [Thu, 8 Sep 2016 16:06:33 +0000 (11:06 -0500)]
output/csv: Add an option to output units for column labels.
This change tweaks the CSV output module to change the label
setting from on/off to units/channels/off, where channels is the old
on behavior, and units uses the meaning field to generate the column
label - except for the generated Time column, which uses the label from
the X axis when it's generating gnuplot output.
Mike Meyer [Fri, 5 Aug 2016 09:52:08 +0000 (04:52 -0500)]
New all-singing, almost all dancing, csv output module.
- It now handles more than one analog value correctly - at least from the
demo driver.
- Add column headers from channel names.
- Add a row dedup capability.
- Add a sample time column.
- Add a frame end formatting (for gnuplot).
- Made almost all formatting controllable or at least optional.
- Fix it so we can mix analog and digital values.
- Add outputting a gnuplot script for the data.
- Count actual channels, not just mine, to find end of sample.
- Add trigger option (untested).
Uwe Hermann [Sun, 28 Aug 2016 21:52:48 +0000 (23:52 +0200)]
Have remaining drivers default to digits=2 for analog values.
The default so far was 0, which meant there would be no significant
digits at all, yielding results that looked strange/wrong to the user.
Long-term all remaining drivers should be fixed to use the actual,
correct digits and spec_digits values according to the device's
capabilities and/or datasheet/manual. Until that is done, a default
of digits=2 is used as a temporary workaround.
projects / libsigrok.git / log