Enhance how the data acquisition is stopped. Wait for the hardware to
flag the successful completion of data retrieval as well as flushing
through hardware pipelines.
Use symbolic identifiers for the mode register's fields (for read as
well as write access).
This commit uses part of a code update to better match the documentation
done by jry@, but not all of it to reduce the size of the commit.
Minor adjustment for improved readability. Don't hide assignments in
variable declarations. Move initialization of some variables closer to
related evaluation or subsequent processing. Break a complicated looking
roundup expression into several short steps.
Fix how the READ_ID register index was passed to the hardware access.
Addresses are sent in nibbles, so shift by eight is wrong here. No harm
was done, as the register's index is zero.
The Asix Sigma driver is aware of three firmware images, which are
required for acquisition with up to 50MHz, 100MHz, and 200MHz. The
previous implementation always downloaded the corresponding firmware
image whenever the sample rate has changed, which was redundant.
Skip the download when the new samplerate uses the same firmware as the
previously selected samplerate did. This results in faster responses in
the GUI when the samplerate selection changes.
Move assignments out of the variable declaration block for improved
readability while we are here.
The hardware provides captured data at a maximum rate of 16bits per 20ns
(50 MHz). For samplerates of 100 and 200 MHz one individual 16bit entity
contains multiple samples for a reduced number of channels. The bits of
several sample points are interleaved within the 16bit entity.
This commit is based on work done by jry@ who fixed a lot of issues with
the help from Ondrej at Asix.
This fixes bug #840.
Adjust the interpretation of acquired sample data such that regardless
of 50/100/200MHz samplerate the assignment of LA pins to sigrok channels
remains stable.
Introduce helper routines to access the sample data that is provided by
the ASIX hardware, as well as the buffer which accumulates logic data
before it gets sent to the session's datafeed.
This hides endianess issues from call sites, and prepares access to
memory layout which varies with sample frequencies.
This commit is based on work done by jry@.
This works around bug #359. Triggers currently are not operational for
Asix Sigma. Don't claim support in the driver so that UIs won't use the
feature. Yet allow research in this issue, by concentrating the switch
for the feature's support in a central location.
Add/update a comment and unobfuscate an error code path while we are here.
Both the .c and the .h file declared the same identifiers for USB
properties of ASIX hardware with identical values. Remove the .c
incarnation and keep the .h content, as the names are used in api.c
as well as protocol.c sources.
Introduce a separate routine which maps sample counts and sample period
to an elapsed sample time after which acquisition shall get stopped.
Add some more time to make sure the most recent captured data has passed
the hardware pipeline and is available for download.
This commit is based on work done by jry@.
When "tsdiff < EVENTS_PER_CLUSTER" we don't want "tsdiff - EVENTS_PER_CLUSTER"
(a negative number) to be treated as (int).
Submitted-By: jry <jrysig@gmail.com>
[ gsi: massaged for mainline submission ]
Bump the number of supported logic channels from 8 to 128. This is
mostly motivated to test the 64 channels limit which some of the
components/subprojects of the sigrok project might have (input/output
modules, user interfaces).
Only automatically enable the first 8 of the 128 total logic channels,
i.e. default to the previous behaviour. Prepare to only enable part of
the set of analog channels, but stick with their being active by default
as well.
Factor out the choice for the default logic pattern, too. This allows
for easier adjustment of the default configuration, when settings are
concentrated in a single spot.
Extend the demo driver, add another waveform choice for logic channels.
Create a "cable squid" logo representation which occupies a large number
of channels.
This pattern occupies 128x128 pixels. Unlike the 'sigrok' pattern it
gets repeated when more channels are involved, but is not shifted in the
repetition.
The handling of the digital channels for this series is somewhere
between that of the DS1000D series (PROTOCOL_V2) and the MSO1000Z
(PROTOCOL_V4).
The :LA command set is similar to that of V4, but the LA data has to be
requested with :WAV:SOUR:LA and arrives in interleaved form like V2.
None of these changes should affect other models. They only affect the
case of PROTOCOL_V3 with digital channels, which occurs only for the
MSO2000A series.
Fixes#933.
We'd already had this problem elsewhere and thus have this wrapper function
that does this where necessary. It just wasn't in use on these two call sites,
which was causing timing problems when used over tcp-raw or VXI transports.
With trigger enabled, and with PulseView, a second (or more) acquisition
starts immediately instead of blocking. It's mandatory to try several times
to have a correct behavior.
According to http://mygizmos.org/ols/Logic-Sniffer-FPGA-Spec.pdf section 2.3.1
p.8, the Openbench Logic Sniffer must be reset before each arm command.
This fixes bug #809.
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Openbench Logic Sniffer reset is a little more complex than a simple send.
To avoid code duplication, this patch adds a new function dedicated to
this task.
Signed-off-by: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
This changes the fx2lafw code to only enable the wide_sampling (16bit)
method, if at least one of the higher eight channels is enabled. This
has the benefit, that we can use higher samplerates on 16bit LA
devices if we use only the first eight channels.
The wide sampling is also enabled if we have one or more analog
channels.
Signed-off-by: Jan Losinski <losinski@wh2.tu-dresden.de>
devc->step is not reset on acquistion start, so acquisition
starts with a different value every time. Thats annoying when
using the demo driver to debug sigrok, so lets make sure that
it's reset to 0.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
sr_period_string takes the frequency as its argument, i.e. the reciprocal
of the timebase. Obviously this will not work for frequencies less than
1Hz / timebases greater than 1 second, but at least is correct for all
other available timebases.
Phrase the logic which checks the use of analog channels and digital
pods in more generic terms. Place a comment about the contraints' being
potentially dependent on the specific HMO model. This implementation
should lend itself better to future adjustment (HMO1002?).
An internal libsigrok implementation detail prevents partial submission
of logic data for different channel groups in multiple calls. Instead
one logic packet needs to be sent in a single call, which combines data
for all channels.
Introduce a logic data storage which folds samples from several channel
groups that were received at different points in time into a combined
memory layout of larger unitsize. Stick with the former shortcut of
passing on the input bytes directly when only the first digital pod is
used during acquisition.
This change correctly maps data from the second pod to channels D8-D15.
The previous implementation only added one of the digital channels to
the list of enabled channels that are involved in the acquisition (the
first one that was found). This means that when the set of used digital
channels spans more than one pod/group, the second pod will never be
read from.
Make sure to enable one digital channel per pod/group, such that
acquisition will retrieve data from all involved input sources.
Add comments while we are here. Mention how the different setup, check,
start, and receive routines which are spread across several files do
interact to achieve acquisition.
The previous implementation used to put FRAME_BEGIN and FRAME_END
markers around each received chunk of samples, while those chunks
correspond to a single channel (analog) or a group of eight channels
(digital) each. In other words, the hameg-hmo driver had provided a
multiple of the requested frames, and those frames were incomplete.
Make sure to only send FRAME_BEGIN before the first channel's data,
and FRAME_END after the last channel's data of a frame. Thus make
sigrok frames exactly match the scope's frames.
Add some comments on the frame marker and the acquisition stop logic
while we are here.
Configure the scope to the host's native endianess before downloading
acquisition data from analog channels. This unbreaks operation on those
models which default to a representation which differs from the host.
When the channel state is retrieved, query the pre-set byteorder for
SCPI data blocks as well. When samples get retrieved during capture,
support float representations in either big or little endian format.
This commit unbreaks devices which operate in BE format by default
(tested with HMO2524). It keeps working with LE format as before. For
devices which don't support the byteorder query or return unknown
responses, LE format is assumed for backwards compatibility. The
device's byteorder is only queried and never set. This makes the
commit least intrusive.
A comment mentioned that the models HMO2524 and above support 16 digital
channels (and thus have two pods for the probes). Move those models to a
section that declares the respective features, including trigger support
on the upper digital channels.
Model detection and reflection of supported channels was tested on HMO2524.
Commit db81fbb582 made sure to release a potentially previously
allocated list of enabled channels before (re-)building the list in the
current invocation of acquisition start.
This commit frees the memory in the error path near the failed creation
already, which reduces the period of time where unused resources are
held, and eliminates a memory leak when acquisition is not stopped after
failed start.
Both approaches can coexist. Freeing an empty list is perfectly fine.
Fix the code which registers the name of the second pod for digital
probes. The previous implementation registered the first pod twice, and
lost the reference to the second pod. No harm was done, none of the
supported models declared support for two pods so far.
Factor out a channel to group mapping in the registration of digital
channels, while we are here.
The former DER EE DE-5000 driver was a very thin wrapper around the
ES51919 LCR meter chipset. None of its source was specific to the
deree-de5000 device. In fact it contained code for all currently
supported LCR meters, and it's expected that all LCR meters which
will get added in the future will fit in as well.
Follow the serial-dmm model. Rename the src/hardware/deree-de5000/
directory to serial-lcr/. Update the configure logic. Although the
source directory and the configure option are named serial-lcr, the
LCR meter still is used by specifying the "deree-de5000" device driver
(which just happens to reside in the serial-lcr driver sources, among
others).
The "deree-de5000" driver is a very thin wrapper around the ES51919
chipset. We expect more models from other vendors to use that same
support code.
Model the registration of vendor/model combinations after the serial-dmm
approach. Register the DER EE DE-5000 device as the currently only
member in a list of drivers which all use the ES51919 chipset (no model
specific routines are registered in the absence of support for other LCR
meter chips).
This commit does not change the driver's behaviour nor the set of
supported hardware. It prepares the addition of more drivers in the
future.
Factor out identical comments on the UART bitrate of ES519xx based
multimeters. These probably got copied from the first item as of 2012
when new items were added in 2014 (the added devices were from the
same vendor and rebadged).
Expand on the fact that the bitrate still is within spec, and does not
harm at all. Strictly speaking the comment could get dropped.
The previous implementation seems to have added drivers in their "order
of appearance". Start sorting the rather long list, to simplify several
tasks: Add new entries as more drivers get written, find existing items
during research, identify and compare similar models during maintenance.
As a byproduct, there will be no doubt about where to put things during
future work :) and duplicates will be spotted immediately.
This commit puts 'bm25x' meters into one group. And comments on the sort
order and motivation for sorting the table.
Add another DMM entry for Peaktech-3330, which is based on the FS9721
chipset. Support was tested with the CP210x based USB cable.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
We now require the use of the latest fx2lafw firmware which uses the
same USB VID/PID (1D50:608E) for the Hantek 6022BE and the variants
and rebadges of that device (e.g. the SainSmart DDS120).
The variants can be distinguished via the USB product version field.
Gerhard Sittig
Uwe Hermann
Angus Gratton
Martin Ling
Johannes Römer
Gwenhael Goavec-Merou
Marc Schink
Bert Vermeulen
Jan Losinski
Soeren Apel
Matthieu Guillaumin
Sven Schnelle
Vlad Ivanov
Sebastian Tabares Amaya
Aurelien Jacobs
Stefan Brüns
Vlad Ivanov
Karl Palsson