Set samplelimit to a sane value (was causing PulseView to
crash earlier), as well as advertise samplerate using SR_CONF_LIST
so that PulseView can show the sample rates.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
The function drains off all the remaining data in the receive socket
and is triggered before starting a capture and after a capture is
completed. In the absence of this function, there is a possibility of
data corruption and also the NodeJS TCP server throws an error if the
buffer is not completely read out before the socket is closed.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
BeagleLogic now supports two modes of interface - one being the
native mode running on an ARM system like the BeagleBone Black
and the other mode acting like a TCP client for the BeagleLogic
server running off a BeagleBone compatible system. This makes it
convenient for desktop users to retrieve samples from BeagleLogic,
no more copying files and SSHing into the BeagleBone hardware in
order to use BeagleLogic.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Organize driver functions into an ops structure (there will be
separate structures for both native and TCP mode of operation).
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
The code earlier was in a single .h file, so it's now separated into a C file
and H file
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
If a channel in the higher-than-8-bit group is enabled then use
16-bit captures. Otherwise just do 8-bit captures.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Starting with Linux kernel version 4.9, BeagleLogic attributes
setting does not require root permissions.
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
This is unlike the previous behavior to return 8 channels and then
use logic_channels to get all the 14 channels
Signed-off-by: Kumar Abhishek <abhishek@theembeddedkitchen.net>
Values like '-0.1' would be parsed as being positive, as the integral
type does not discern +0 and -0. Also allow values without leading
integral value, to match behaviour of strtod/sr_atof.
This was leading to an invalid threshold config value and indirectly
to frontend issues.
Slightly modified patch from James Churchill <pelrun@gmail.com>, thanks!
The previous implementation unconditionally submitted analog data
whenever values could get extracted out of received serial packets.
This commit checks the channels' enabled state before submission. Care
is taken to obey the user's acquisition limits, exclusively counting
submitted not received values.
Upon reception of serial data from the ES51919 LCR chipset, the data for
channels P1 and P2 was extracted from the packet, and unconditionally got
sent to the sigrok session.
Do check the channels' enabled state before submission. This fixes for
serial-lcr what recently got reported for a Brymen DMM. Tested with
$ sigrok-cli -d peaktech-2170:conn=/dev/ttyUSB0 --channels P2
and other --channels specifications.
The es51919_serial_clean() routine is called by std_dev_clear_with_callback().
Common code unconditionally frees the 'priv' part. The cleanup callback only
shall release descending resources which are local to the callee and opaque
to the caller.
This fixes a double free error. Tested with PeakTech 2170.
$ sigrok-cli -d peaktech-2170:conn=/dev/ttyUSB0 --show
When the acquisition was stopped before a configured limit was reached,
no sample data was retrieved. This is because the api.c stop routine did
unregister the receive callback.
Pass the stop request to the receive routine instead when stop is called
while the acquisition is still running. Have sample data downloaded very
much like it's done for reached limits, and existing logic will run the
stop routine again after state was advanced to "idle".
Extend the 'state' tracking while we are here, mark sample download as
well (that was omitted in the previous implementation). Though the
omission was non-fatal. Move the release of 'dram_line' to some earlier
location (as soon as the resource is not needed any longer), before some
rather complex calls to other routines will execute.
Reported-By: Michael Kaplan <M.KAPLAN@evva.com>
Move the check for the capture ratio being 0..100 into the wrappers,
drop unneeded helper functions, fix incorrect variable types, minor
other consistency fixes.
This makes the code more consistent with the rest of the code-base
and also allows std_gvar_min_max_step_array() to work here.
Without this change:
src/hardware/scpi-pps/api.c: In function ‘config_list’:
src/hardware/scpi-pps/api.c:570:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->voltage);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:573:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->frequency);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:576:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->current);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
This ensures consistent handling of the SR_CONF_SCAN_OPTIONS and
SR_CONF_DEVICE_OPTIONS (with sdi NULL or non-NULL) config keys
and also reduces copy-pasted boilerplate in the drivers a bit.
This function does not handle channel-group specific items, that's
very driver-specific and thus left to the individual drivers.
Also move some generic checks and error messages from the drivers into
the sr_config_list() wrapper.
The HW simply stops sending data on overflows, so if we receive no data
in one second, we abort the acquisition. We also need to allocate more
buffers to support higher sample rates.
Until now, clear_helper() callbacks for std_dev_clear_with_callback()
were expected to g_free(devc), but not all of them did that.
Have std_dev_clear_with_callback() unconditionally g_free(sdi->priv)
(i.e., devc), regardless of whether a clear_helper() callback was
provided or not. It was doing g_free(sdi->priv) when no callback
was provided already anyway.
This makes the individual drivers' clear_helper() implementations
shorter and prevents errors such as missing g_free(devc) calls.
This works, because all drivers either call std_dev_clear_with_callback()
directly, or indirectly via std_dev_clear().
This also allows us to remove some no-longer needed dev_clear()
and clear_helper() implementations that only did g_free(devc)
in favor of std_dev_clear().
Be explicit and consistent in the drivers about which dev_clear function
will be called to avoid confusion and inconsistencies.
Drop some open-coded implementations of std_dev_clear().
Kumar Abhishek
Uwe Hermann
Stefan Brüns
Joel Holdsworth
Frank Stettner
Marcus Comstedt
turboaffe
Gerhard Sittig
Jan Luebbe