Tested on an MSO1104Z with firmware 00.04.02.SP4.
The analog channels are captured correctly. For the MSO series, with digital
channels, there are two outstanding issues:
1. Logic data is retrieved per-channel, one byte per sample, with the value
in the LSB of each byte. The current datafeed logic format doesn't allow
this format to be passed on directly. I suggest we resolve that rather than
making the driver buffer and interleave the data.
As stands, the code will retrieve data for all channels and pass it onto
the datafeed with unitsize=1. Channel D0 can used correctly if selected
alone. For other channels, data is passed to the frontend but the API does
not provide a way to associate it with the correct channel.
2. Channels CH3 and CH4 are multiplexed with D0-7 and D8-15 respectively, so
enabling these is mutually exclusive. We don't currently have a way to
express this constraint to the frontend.
This patchset was originally done by eightdot <gituser@eightdot.eu> by
manually forward-porting parts of the changes done by Bert Vermeulen (see
previous commits), but then heavily modified by Uwe Hermann to be based on
top off the (git-)rebased patches from Bert Vermeulen instead.
Note: This initial DSLogic code is *not* yet in a working or usable
state. It should be considered as a basis for further work only, for now.
CC src/hardware/openbench-logic-sniffer/api.lo
../src/hardware/openbench-logic-sniffer/api.c: In function 'scan':
../src/hardware/openbench-logic-sniffer/api.c:103:10: warning: unused
variable 'probefd' [-Wunused-variable]
GPollFD probefd;
^
Use the more portable sp_input_waiting() instead of g_poll() with FDs.
Thanks to Martin Ling for the hints. This is tested on Linux and Win7
using an OLS; scanning for the device and starting an acquisition works.
Also, add some more debug output.
This fixes bug #562.
Split device options into general and channel group settings, and
adjust config_list() callback appropriately.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
There's indeed no g_fclose() unfortunately. The g_*() wrappers for file
handling are mainly there to deal with portability issues in file names
(encoding, character sets, etc) on different platforms.
Use PRIu64 to avoid the following compiler warning:
CC src/hardware/baylibre-acme/gpio.lo
protocol.c: In function 'bl_acme_set_shunt':
protocol.c:341:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' [-Wformat=]
g_fprintf(fd, "%llu\n", MOHM_TO_UOHM(shunt));
^
Implement support for SR_CONF_PROBE_FACTOR setting in BayLibre ACME
driver. Given the channel-group parameter this allows to set the
shunt resistance for each probe.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Implement basic functionalities for baylibre-acme. Add support
for common config options, device detection and sample reading.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We try to find the smallest diff by comparing each diff with
the previously known smallest diff, so initially, this smallest diff
should be INFINITY so that we are sure to find a smaller one.
This fixes the following exception:
sr: rigol-ds: Negative vdiv index: -1.
Caught exception: not applicable
These are available on e.g. Rigol DS1102E (or "upgraded" DS1052E).
Without this, if one of the channels happens to have been set to
one of the missing vdiv settings frontends (e.g. PulseView) will
have some trouble using the scope:
sr: hwdriver: sr_config_get(): key 30012 (vdiv) sdi 0x11bcb70 cg CH1
sr: rigol-ds: Negative vdiv index: -1.
std::exception
(lwla_convert_trigger): Fix trigger mask computation bug introduced
by recent change: Widen constant to 64 bit before shifting so that
channel nunmbers beyond 32 are processed correctly.
Use g_malloc0() for small allocations and assume they always
succeed. Simplify error handling in a few places accordingly.
Don't always sanity-check parameters for non-public (SR_PRIV)
functions, we require the developers to invoke them correctly.
This allows further error handling simplifications.
It fills the fields with reasonable default values that should suit
most of the drivers. Drivers are obviously free to override the fields
they want after initializing.
If the number and specs of the device's channels are not static, i.e.
need to be probed, this facility is needed.
Initially this will be used for the Philips PM2800 series, where only
the model returned by *IDN? is needed. However this could also be used
to do actual discovery with vendor-specific SCPI commands.
At least the Rigol DP800 series trigger the beeper when changing
channels remotely. Which gets rather annoying when doing acquisition
on three channels as fast as you can.
Add a driver for the DER EE DE-5000 LCR meter. This meter is based on
the Cyrustek ES51919/ES51920 chipset and communicates with the host
computer via an optional connectivity kit.
The kit uses an optoisolated unidirectional link to connect to the
meter and an USB cable on the host side. Internally the connection is
using the FTDI FT232R USB UART chip i.e. from the host computer point
of view the meter is connected into an RS-232 serial port.
This driver implements just a thin shim layer for registering the
driver and uses the es51919 module for all the actual work.
Set this new parameter to 0 (no timeout) at every call site. This is
consistent with previous behaviour, so cannot cause any regressions.
Waiting forever for a serial operation is clearly always wrong. Without
specific knowledge of each device and driver however, I can't choose
appropriate timeouts for each call. The maintainers of these drivers
will need to do so, and also add appropriate handling of timeouts.
When this commit is merged, a bug should be entered for each driver
that is touched by it.
Previously, sdi->index was used to tell several identical fx2lafw-compatible
devices apart. This was a bit of a hack, so this patch makes it use physical
device connections instead. They're guaranteed to remain the same even if
the USB device reconnects.
These calls are executed from an event handler and were previously nonblocking,
but they have no partial read/write handling. The code is already marked TODO
for improvement.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
This call was previously explicitly nonblocking, but has no partial write
handling. It sends a short packet so should be OK to block, most likely the
output buffer will be empty anyway.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
These calls are executed from an event handler and were previously nonblocking,
but have no partial write handling. They send short packets so should be OK to
block, most likely the output buffer will be empty anyway.
Fix error handling for some: serial_write can return any negative error code.
This call was previously nonblocking, but there is no handling of partial
writes. It is called from config_set where it is free to block.
Also fix error handling: serial_write can return any negative error code,
not just -1.
These calls were already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. They only read one byte. A return value of zero is not
handled, but should not occur in theory due to the G_IO_IN check. It might be
good to add handling of a zero return anyway, since I'm not sure if this is
always accurate.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
These calls are executed from an event handler and were previously nonblocking,
but have no partial write handling. They send short packets so should be OK to
block, most likely the output buffer will be empty anyway.
Also fix error handling for these calls, which seems to have been retained from
previous direct usage of write() to a serial port fd.
These calls were previously nonblocking, but have no partial write handling.
They are made from scan and acquisition_start contexts where they are free
to block.
Remove the SERIAL_NONBLOCK at open, which only applied during scan, since all
calls in the scan are now explicitly blocking.
Also fix error handling for these calls, which appears to have been kept
from a previous direct usage of write() on a serial port fd.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. Only one byte is read. The case of 0 being returned
is not handled, but the call is only made if G_IO_IN occurred so in theory,
there should be a byte available. It might be wise to add handling for a
return of 0 nonetheless, as I'm not sure if this is always accurate.
This is an odd one. These calls are made from a receive handler so should not
block, and appear to be setup correctly to handle partial reads or no data
available. However, the driver was not opening the port with SERIAL_NONBLOCK
so these calls would have been blocking. Make them nonblocking.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
These calls were already nonblocking since this driver opened the port with
the SERIAL_NONBLOCK flag. Having marked them as such, we can remove the flag.
Also remove an unnecessary reopen of the port to change its blocking status.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
This is called at scan time so free to block. There is no partial write
handling and a response is expected afterwards. This should therefore be a
blocking call.
This call is executed from an event handler context was previously
nonblocking, however there is no handling for a partial write.
The output buffer is unlikely to be full and the commands to be sent
are short, so it should be OK to make this a blocking call.
This call is executed at scan time so is free to block. There is no
handling for a partial write and a response is expected immediately
afterwards. It should therefore be a blocking call.
Every driver now publishes its device option config keys, i.e. the
list fetched with sr_config_list(SR_CONF_DEVICE_OPTIONS), with a
set of flags indicating which methods are implemented by the driver
for that key.
The config keys are OR'ed with any combination of SR_CONF_GET,
SR_CONF_SET and SR_CONF_LIST. These are defined as the high bits
of the uint32_t config key. Clients can OR config keys with
SR_CONF_MASK to strip out these bits. This mask will be kept up to
date if other bits are added to the capabilities list; clients MUST
therefore use SR_CONF_MASK for this.
Some keys don't have capability bits added, such as the informative
device type keys (SR_CONF_MULTIMETER, SR_CONF_OSCILLOSCOPE, ...) and
SR_CONF_CONTINUOUS.
Scan options do not have capabilities bits.
From sigrok's point of view, this analyzer has two differences:
* It does not require uploading the firmware.
* It returns garbage in some registers used for sanity checks.
Saleae's software ignores that garbage; sigrok only does if it
specifically detects the mcupro clone.
Previous runs of dev_acquisition_start() keep the enabled_channels list
populated if they fail. This means that once an invalid channel
configuration was detected, it will be detected again even if the channel
configuration was changed. With this change, the list will be cleared
before being populated so that any stale entries are removed.
The Brymen BM25x series supports the BC-20X that is an opto-isolated
serial cable. The link seems to be unidirectional i.e. when activated
the DMM periodically sends updates to the host while the host cannot
control the DMM in any way.
The protocol is documented in "6000-count-digital-multimeters-r1.pdf"
that is available from the manufacturer. Every 15 byte packet consists
of a bitmap where the bits correspond to segments or symbols on the
LCD display i.e. the DMM essentially sends the contents of its screen
to the host in every update. This driver then decodes the measured
quantity, unit and its value from the bitmap.
Uwe Hermann
Martin Ling
Bartosz Golaszewski
eightdot
Bert Vermeulen
Baruch Even
Aurelien Jacobs
Daniel Elstner
Mathias Katzer
Tim Hatch
Uffe Jakobsen
Soeren Apel
Janne Huttunen
Matthias Heidbrink
Peter Zotov
magnuskarlsson
Marc Schink
Marcus Comstedt