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.
Erik Montnemery [Thu, 18 Aug 2016 21:05:11 +0000 (23:05 +0200)]
hantek-6xxx: Ignore requests to set Hantek 6022BE coupling.
Here's a patch to "Ignore requests to set coupling for the Hantek 6022BE",
this clears the LIBUSB errors for me.
Also in the patch:
- There is a crash because config_list() can be called with sdi == NULL.
This can be reproduced by doing:
"sigrok-cli.exe --driver hantek-6xxx --show"
- There seems to be a very unsafe loop in config_set() when setting COUPLING;
the coupling vector is assumed to be zero terminated, but is not declared
as such.
Note: The same issue is present also for other hardware, at least for
hantek-dso/api.c. The patch is only for hantek-6xxx though.
Uwe Hermann [Sun, 14 Aug 2016 21:51:49 +0000 (23:51 +0200)]
hantek-6xxx: Fix some issues by using power-of-two data sizes.
There were issues when using non-power-of-two data sizes with e.g.
the Hantek 6022BE device. For example, on Windows the acquisition would
simply hang and never complete:
hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_ERROR received 0 bytes
The issue was reported by Erik Montnemery on the mailing list, the
original patch was posted by "mmark" here (thanks!):
Aurelien Jacobs [Mon, 20 Jun 2016 20:58:12 +0000 (22:58 +0200)]
analog: add support for negative number of digits
When a meter display 105.2 kΩ, libsigrok will return 105200 Ω
but it is really valuable to know that the last 2 digits are not
significant, so encoding.digits should be set to -2.
This would allow a sigrok client to display 105200 as 105.2 k
instead of 105.200 k.
Aurelien Jacobs [Sun, 5 Jun 2016 21:10:44 +0000 (23:10 +0200)]
group all drivers into a single object
This single object also contains the sr_drivers_init function, that will
always be referenced. That ensures that the drivers object files won't
be optimized out during static linking due to the fact that they are
not referenced directly.
projects / libsigrok.git / log