The bandwith in Rigol DS1xx2D/E scopes can be upgraded to 150 MHz in software.
So detect also scopes with the upgraded bandwith.
using libsigrok-0.2.1 + this change + commit da970d24ec (required for newer kernels):
[dan@eagle sigrok]$ sigrok-cli --scan -d rigol-ds1xx2 -l 5
sr: libsigrok loglevel set to 5.
sr: Sanity-checking all drivers.
sr: Sanity-checking all input modules.
sr: Sanity-checking all output modules.
srd: libsigrokdecode loglevel set to 5.
sr: hwdriver: Initializing driver 'rigol-ds1xx2'.
sr: serial: Opening serial port '/dev/usbtmc0' (flags 1).
sr: serial: Opened serial port '/dev/usbtmc0' (fd 7).
sr: serial: Wrote 5/5 bytes (fd 7).
sr: serial: Closing serial port /dev/usbtmc0 (fd 7).
sr: rigol-ds1xx2: response: /dev/usbtmc0 [Rigol Technologies,DS1152D,DS1EU150XXXXXX,00.04.01.00.02]
sr: hwdriver: Scan of 'rigol-ds1xx2' found 1 devices.
The following devices were found:
rigol-ds1xx2 - Rigol Technologies DS1152D 00.04.01.00.02 with 18 probes: CH1 CH2 D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 D11 D12 D13 D14 D15
Most Metex DMMs use e.g. " mV" as unit field, others use "mV ",
though. Support these (and other) whitespace variants by stripping all
spaces and only comparing non-space characters.
If buf contains exactly the string "Agilent Technologies" (for example if
there are bugs in the timeout logic or serial driver causing the reply from
the meter to be abridged) then this code will SEGV. This is because tokens[1]
is NULL but only tokens[2] and tokens[3] (both of which are undefined) are
NULL checked.
Can be trivially corrected by NULL checking tokens[1] as well.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
g_usleep(XX) sleeps for *at least* XX microseconds but may sleep for
longers (on older kernels the sleep will typically be 10000us). Thus
byte receive loops containing an unconditional sleep will perform
very poorly (for example it causes the scan in agilent-dmm to timeout
prematurely).
Even on modern kernels serial_readline() has a 2ms sleep per byte which
means it will read at a maximum rate of half a character per millisecond
(~4800baud).
This is fixed by only sleeping when read() returns no data.
Signed-off-by: Daniel Thompson <daniel@redfelineninja.org.uk>
This DMM is not using the standard bits in the FS9922 protocol/structure
to indicate the "volt" and "diode mode" flags. Instead, it only sets the
user-defined bit "z1" to indicate both "diode mode" and "volt".
This fixes#142.
This is no longer used, and also it is not available on Android and thus
breaks cross-compilation for Android.
Thanks Marcus Comstedt <marcus@mc.pp.se> for reporting.
For demux mode we half the channels. Previous check method broke
the OLS randomly and but it in a bad state.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
demux mode allows DDR sampling which disables group 2 & 3
and thus samples group 0 & 1 to sample on rising and falling of
the clock.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Allow channel groups to be swapped. This is useful
for demux at 200mhz with the unbuffered channels.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
The high bit of the sample, denoting this is a count, was not getting
properly cleared. This resulted in an inevitably negative count, and
corruption of the sample buffer before it was transferred to the
frontend.
The single sample buffer, up to 4 bytes long, was not getting initialized
on (every) acquisition start, only after the first full sample was in.
This caused the first sample to potentially hold garbage.
ols allows both external and internal test patterns at ~20khz
which are helpful for unit tests and demos.
pattern=internal -> route pattern internally to all 32 pins
(input otherwise disabled)
pattern=external -> generates pattern on unbuffered pins 16:31
(which can be looped back to the buffered pins 0:15)
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
Stage count was always getting incremented one more than
actual stages, and this caused a extra stage with zero'ed data
probe lines to have the start bit field.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
The map_eeprom_data function is currently unknown. The map entries
provided were observed via bus-snooping of the vendor software on my
device. Other devices may need additional values.
Since the uni-t-ut32x series handles devices with the same USB VID.PID,
which is linked to the WCH CH9325 USB/HID-UART interface chip, this
driver can no longer assume it can handle anything with this VID.PID.
The Tecpel DMM-8060 was added since we assumed it would be a rebadged
Voltcraft VC-820 (since we know the Tecpel DMM-8061 is a rebadged VC-840).
However, according to the vendor webpage it doesn't have PC connectivity
at all, so drop it for now (until someone can confirm that it does or does
not actually have RS232/USB connectivity).
Can't really count on it either way though, the device is just
too flaky to conclude whether it's going to work or not, regardless
of the status returned.
The per-driver API calls no longer have a hw_ prefix (e.g. hw_init()
became init() and so on), so drop the 'hw_' from the std versions
for those API callbacks too.
These two drivers are currently unfinished and don't work, so disable
and "unhook" them for now in preparation of the next libsigrok release.
They're still in the git repository, but not hooked up to the build
system, so that they won't get detected or built, and also don't end up
in the release tarball.
Since link-mso19 is the only driver that currently requires libudev,
drop any reference to that, too.
It should be relatively easy to apply this patch in reverse after the
release to bring back both drivers.
This invalidates previously returned sr_dev_inst pointers, which a
frontend may be holding. It's the frontend's responsibility to clear
the list of instances a driver keeps track of by calling
sr_dev_clear(driver);
if it wants a completely new scan done.
Use the same functions and structs as the other DMM protocol parsers
in hardware/common/dmm. Among other things, this allows the functions
to be used from drivers in a generic way, e.g. in serial-dmm, uni-t-dmm,
and possibly other drivers.
These two drivers are currently unfinished and don't work, so disable
and "unhook" them for now in preparation of the next libsigrok release.
They're still in the git repository, but not hooked up to the build
system, so that they won't get detected or built, and also don't end up
in the release tarball.
Since link-mso19 is the only driver that currently requires libudev,
drop any reference to that, too.
It should be relatively easy to apply this patch in reverse after the
release to bring back both drivers.
This off-by-one was clobbering the stack since introduced in a803c0db4d.
However it only set one bit, and that generally appears to have been set
already, so this rarely affected anything. But when it did, it affected
a pointer, causing a segfault.
- If libusb-1.0 is not found, do not compile in ezusb.c and usb.c since
they require libusb.h. The respective hardware drivers that use
libusb-1.0, and usb.c and/or ezusb.c will be excluded from the build
elsewhere in configure.ac. Rename NEED_EZUSB to NEED_USB.
- Drop the NEED_SERIAL check and always compile in serial.c. This is a
very small chunk of code, it does not depend on any external
libraries that might be missing, and it compiles on all architectures.
Thus there's no need to conditionally include or exclude it.
The currently supported model LAP-C(16032) doesn't support the
samplerates 150MHz and 200MHz which some of the other models have.
Thus, do not report these samplerates to the frontends. E.g. sigrok-cli
should not show them via --show and GUIs should not list them in their
"Samplerates" drop-down.
- Explicitly list .config_get in all drivers for consistency, and set it
to NULL if unused (whether or not a driver implements it is optional).
- List all 'struct sr_dev_driver' entries in the same order in all drivers.
- Move the check whether .config_set/.config_list exist (i.e., are non-NULL)
into sanity_check_all_drivers().
This is a small helper function which sends the SR_DF_HEADER packet that
drivers usually emit in their hw_dev_acquisition_start() API callback.
It simplifies and shortens the hw_dev_acquisition_start() functions
quite a bit.
It also simplifies the input modules which send an SR_DF_HEADER packet, too.
This patch also automatically removes some unneeded malloc/free in some
drivers for the 'packet' and 'header' structs used for SR_DF_HEADER.
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
This patch might also work for a number of other Brymen models
-- 859(a), 867, 869---
including their respective rebadges from Greenlee, Extech, and Amprobe.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
Also, do some minor whitespace and consistency improvements.
Check the relevant arguments for != NULL before calling the actual
driver-specific function, so that the driver can safely assume those
arguments are non-NULL. This removes the need to duplicate these
checks in every driver.
Also, change one SR_ERR to the more correct SR_ERR_MALLOC, and assign
sr_ctx in the rigol-ds1xx2's hw_init() function, like all the other
drivers do.
Sending an SR_DF_META packet at the start of every stream is not
mandatory; the frontend should ask for what it needs, and any extra
information the driver wants to send will come in due time.
Currently hw_info_get() can receive requests for entries (info_id) that
the specific driver doesn't support. That is (right now) a valid
use-case and not an error (might change later, though).
Thus, for now, don't output messages for such requests at all (certainly
not as sr_err() where they show up in e.g. sigrok-cli output per default).
Errors while opening or configuring ALSA devices during scan for devices
should not be shown by default (i.e., no sr_err() usage). Non-working
or non-accessible devices (due to permissions or other reasons) will
simply not show up in frontends. Use sr_dbg() instead of sr_err().
Fix the bare minumum of whitespace/indentation/coding-style via
automatic 'indent' run, followed by some minor manual fixes.
Some more fixes and cleanups might follow later.
Bring back the original (C) lines from before the split into api.c
and protocol.[ch].
Add "Copyright (C) 2013 Lior Elazary <lelazary@yahoo.com>" since there
were nontrivial changes to those files.
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>
commit 378abfeac6 tried to solve a bug where
the fx2lafw driver would print "Device came back" even if a timeout had occured.
It solved that issue, but inadvertently introduced a new bug:
"Device came back" would be printed even if no firmware upload was performed.
This is counterintuitive, as the device is only reset when a firmware upload is
performed.
There are three cases:
i) Firmware upload was successful
ii) Firmware upload failed
iii) Firmware upload was NOT needed
Each case warrants a separate message from the driver. Print the
following messages depending on the outcome:
i) "Device came back"
ii) "Device failed to renumerate"
iii) "Firmware upload was not needed."
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the new DRIVER_LOG_DOMAIN mechanism, where explicitly writing
the driver name in the message string is no longer required.
Thus:
- sr_err("fx2lafw: Something bad happened.");
becomes:
+ sr_err("Something bad happened.");
In either case, the log output is the same.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This works with the UNI-T UT-D02 (RS232) cable. For the USB/HID
based cable (UNI-T UT-D04), the uni-t-dmm driver must be used.
Note: This is untested, but should work just fine for all settings, with
the possible exception of temperature (testers needed!)
Just use the 'int dmm' + wrapper method that is used for all other
functions which need this information. There is no real need to
special-case the hw_dev_acquisition_start() API call here.
The rs9lcd parser, which is used for the RadioShack 22-812 does not use its
*info parameter, and therefore did not have a rs9lcd_info struct declared.
With recent re-factoring of the receive data callbacks, it became necessary to
pass a struct pointer. This made the RECV_DATA macro look like:
- RECV_DATA(RADIOSHACK_22_812, metex14)
giving the wrong impression that the RadioShack 22-182 uses the
metex14 protocol, which is not the case.
Create a dummy rs9lcd_info struct, and correctly identify the parser
as rs9lcd in the RECV_DATA macro:
+ RECV_DATA(RADIOSHACK_22_812, rs9lcd)
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Not all drivers use subdrivers. The only reason the subdriver field was
introduced was to accomodate the model of serial-dmm.
The sr_dev_driver struct is available to the frontend. Exposing the subdriver
field creates the problem of exposing knowledge of libsigrok's internal driver
layout, even though the drivers are designed to be a flat list to the frontend.
Store the subdriver in the dev_context struct of serial-dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
The global *di alias was used to keep track of the driver context.
It caused issues with trying to use several subdrivers at once, so
its use was obsoleted.
The correct context is preserved through different mechanisms, either
the *sdi pointer, or wrappers which pass the correct context.
The *di alias is no longer used, so remove it.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Wrappers for hw_init, hw_cleanup, clear_instances, and hw_scan are needed for
each subdriver due to the nature of serial-dmm. These wrappers are implemented
as macros, in order to reduce the number of lines of code.
For each of those functions, we have a separate wrapper list, then we connect
them together in a first-class driver using a DRV macro, and yet another list
(the DRV list).
Instead of declaring those wrappers in separate lists, include them in the DRV
macro. This approach reduces the number of macro lists from five to just one.
From the perspective of adding a new subdriver, this also greatly reduces the
number of places needed to hook in a new device.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Store/use the receive_data() function and a pointer to the driver struct
in the dmms[] array. Use a ".subdriver" entry in the driver struct.
Use a macro to simplify hw_init() wrappers.
Declare dmm_info dmms as extern in protocol.h to prevent duplicate
symbol error from the linker.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
di was initialized as NULL. If no device covered by this driver
is used, di remains NULL. This causes a segmentation fault when
calling clear_instances().
Check for di being NULL.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Use the infrastructure of serial-dmm to handle the RadioShack 22-812,
and completely remove radioshack-dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Move the parsing part of radioshack-dmm into a separate protocol
parser, following the model from hardware/common/dmm.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
During scan the serial port is opened with SERIAL_RDONLY | SERIAL_NONBLOCK,
which works fine, but when acquisition starts, it is opened only with
SERIAL_RDONLY. On Linux, if cdc_acm can make a claim to the USB to serial
converter, opening the port will fail.
Open port with SERIAL_RDONLY | SERIAL_NONBLOCK.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
We already have an event-based mechanism in place. Using a thread just
adds unneeded complexity, especially for a driver designed not for
performance, but for providing a testbed to frontends.
Generate the data in the event handler, not in a separate thread.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
strcmp(buf + 9, " mA") does not work because buf is CR-terminated,
while " mA" is NUL-terminated.
Drop ambiguities arising from the termination of the strings, and
only compare the characters we care about, using strncmp().
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When the parser found a space, it treated it as an invalid digit
and discarded the whole packet. This behavior was incorrect on
2000 count devices, where the first digit can be sent as a space
rather than a '0'.
Convert spaces to '0' and parse them as usual.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Prepare the tekpower-dmm driver to be able to support various simple
serial port based DMMs.
Also, make a 'tekpower-tp4000zc' "first-class" driver which is currently
the only user of this generic driver.
The demo driver was using sr_session_source_add_channel() to add
a poll source, but was relying on sr_session_run_poll() to call
sr_session_source_remove(). This, coupled with the design of the
driver caused errors once the samples were collected.
The error stream was most likely related to failing to properly close
one of the channels.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
This is the first step in fixing the demo driver: figuring out what is
being called and what is not _and_ have it show up in the logs.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Options in addition to the usual "9600/8n1" syntax start with a
slash, and take the form of key=value, where different options are
also separated by slashes. For example:
"9600/8n1/rts=0/dtr=1"
This sets RTS low and DTR high.
The packet mode byte is akin to a signature. If that is invalid, there's
no point in calculating the checksum, so check the mode first.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Serial detection was using serial_readline, which stripped carriage
return from the packets. This made for a very unreliable detection
mechanism.
Switch to a timeout-based detection mechanism that parses the data
as it comes in. This also allows us to stop parsing once we found
our first valid packet.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>