Since we are using the 'hw' interface of ALSA, we don't have the luxury of
samplerate conversion, given by the 'plughw' interface. If we try to set a
samplerate that is not supported, ALSA will just throw an error.
We can test for the supported samplerates, and create a list of supported
samplerates, then limit the selection to only those values. The frontend can
query the list of supported samplerates.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The alsa driver requested signed 16-bit integers from ALSA, but casted them to
to an unsigned 16bit before finally casting them to a float. The end result was
that half of the wave would be clipped off.
We also requested data in little endian format. ALSA can be instructed to send
data with the correct endianness for the platform, without needing to worry
about what that is.
This patch attempts three points, which, together, fix the acquisition:
1) Request data from ALSA without specifying endianness; ALSA will handle the
endianness.
2) Simplify the int16_t to float loop by using straightforward indexes.
3) Normalize every value before sending it on the session bus.
NOTE: If testing with PulseView, it will appear as if sigrok is sending all
zeroes. sigrok is sending correct data, but since the data is normalized,
PulseView will incorrectly plot it as a straight line.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The alsa driver only works with device "default". This limits the driver's
scope to whatever device ALSA deems to be "default". It is desirable to have
access to all ALSA devices from sigrok.
Change the alsa device scan so that:
Each alsa device (not alsa card) gets its own sigrok device
For example,
hw:1,0 == sigrok device 0
hw:1,1 == sigrok device 1
hw:2,0 == sigrok device 2
hw:2,1 == sigrok device 3
hw:2,2 == sigrok device 4
[...]
We don't currently look at alsa subdevices. We only use subdevice 0.
Every input device will have its own channels (left, right, etc). Each of
those channels gets mapped to a different sigrok probe. A device with 4
channels will have 4 probes from sigrok's perspective.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
snd_pcm_hw_params_set_rate_near() will try to use the samplerate closest to the
given value, potentially starting the acquisition with a different samplerate
than the one specified.
Instead, use snd_pcm_hw_params_set_rate(). It will return an error if the
samplerate is not supported by the hardware, which is arguably better than
collecting data with a different samplerate than the one specified.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
asix-sigma.c:648:9: warning: 'ret' may be used uninitialized in this
function [-Wmaybe-uninitialized]
asix-sigma.c:1337:20: warning: 'triggerselect' may be used uninitialized
in this function [-Wmaybe-uninitialized]
This matches the _ser suffix of the other functions/variables for this
device ("ser" denotes that it is used with the serial UNI-T UT-D02 cable
as opposed the USB/HID based cables which are handled by the uni-t-dmm driver).
But more importantly, the _SER suffix for the enum value will prevent
name clashes later, when the uni-t-dmm driver gets a VOLTCRAFT_VC820 enum.
Do the same for VOLTCRAFT_VC840.
Check whether a sample limit was actually set (> 0) before checking if
that sample limit is reached. This also fixes continuous acquisition mode
for drivers which have that.
Implement SR_HWCAP_LIMIT_MSEC capability, to allow acquisition to automatically
stop after a specified amount of time.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Some unusual modes required re-parsing the value. Instead of assigning the
re-parsed value to *floatval, it was reassigned directly to *analog->data;
however, analog->data is not initialized at this point, causing a segfault.
This situation was created when moving the radioshack-dmm code to serial-dmm,
with the segfault not being observed at that time.
Do not write directly to analog->data, but instead use the intermediate
variable rawval.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Convert bit masks from hardcoded hex values to bit shifts. For example 0x80
becomes (1 << 7). This also fixes a typo error in the definition of INFO_DIODE.
Add comments explaining that some case values in sr_rs9lcd_parse() are meant to
fall through without a 'break;', and explain some of the unusual modes.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Unfortunately the device doesn't have an EEPROM on board at all, and so
initially enumerates with the default Cypress FX2 VID:PID (04b4:8613).
Since we already support using plain FX2* as basic logic analyzers using
the fx2lafw firmware, we cannot support that same VID:PID for the
OsciPrime. Therefore a USB conn is required for the initial scan.
However, once the firmware is uploaded the device re-enumerates as
04b4:1004, which we do detect for scanning automatically.
Thus, the OsciPrime driver requires one scan with conn parameter to get
the firmware uploaded, but it will then keep working until powered off.
This is the driver model agreed upon for all drivers.
As a result of the split, a devc->num_probes field had to be added in order to
reduce the interdependence between api.c and protocol.c .
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
serial-dmm does not check if a sample limit is actually in place before deciding
to stop acquisition. Since the sample limit is set at 0 by default, operating
in continuous mode will cause acquisition to stop before even sending the first
sample.
Check to make sure we actually are in a sample-limited mode before stopping for
this reason.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The alsa driver was out of date wrt APIs and libsigrok conventions in
general, and wasn't compiling.
This fixes the compile and updates it to _basically_ work with the current
state of analog support in libsigrok.
This is not finished/full support for ALSA analog sampling yet, though,
various TODOs remain that will be addressed later.
Hardware scanning creates an ftdi_context before attempting to locate devices
based on PID/VID. If no devices are detected, execution jumps to cleanup. The
context is freed with free(), instead of ftdi_free().
We cannot assume that the libftdi context is stored in a contiguous memory
region, and thus cannot use a simple free. Case in point, this situation is
identified by valgrind as a "definitely lost" memory leak.
Use ftdi_free() instead of a simple free() in hw_scan(). Valgrind no longer
complains about a memory leak in this area.
clear_instances() does not need any modification, as it correctly uses
ftdi_free().
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Martin Ling
Uwe Hermann
Alexandru Gagniuc
Bert Vermeulen
Joel Holdsworth