The asix-sigma driver was reported to fail in combination with newer
libftdi versions, because the firmware upload routine opened again an
already opened device, and then failed to claim the interface. Which was
not fatal before with previous libftdi versions.
Remove the redundant open call. Remove the local FTDI context variable,
which brings the firmware upload routine in line with all other calls
that communicate to the USB device.
This fixes bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
The asix-sigma driver supports different samplerates, which will involve
different firmware images and will affect the number of available logic
channels as well as their memory layout in downloaded sample data.
Make sure to only store the configuration's parameters after the setup
of that configuration has successfully completed, and make sure to store
a consistent set of parameters. Specifically don't change the number of
channels when the firmware upload failed.
This fixes part of bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
The firmware upload code paths in the asix-sigma driver used to return
either the SR_OK code, or the magic number 0 for error conditions. Which
happens to be identical and cannot be told apart by callers.
Provide proper SR_ERR return codes for error conditions, such that
callers can tell whether the firmware upload succeeded.
This fixes part of bug #471.
Suggested-By: Marian Cingel <cingel.marian@gmail.com>
Adjust the string to boolean conversion for an edge case. Accept empty
text (either NULL or empty strings) to mean true instead of false.
This behaviour is more useful from the user's point of view, when the
option's name alone will enable a feature, and an explicit "option=yes"
specification is not strictly necessary. All calling applications in
mainline already implemented this semantics.
Split the data type detection from the actual data type conversion in
the ConfigKey::parse_string() method. Allow the Option class to re-use
the public ConfigKey method, to share the maximum amount of data type
conversion code for both Driver and InputFormat option specs.
This is the least intrusive yet most reliable and consistent approach in
the libsigrok C++ binding that allows applications to support driver scan
and input file format options from command line arguments.
../src/hardware/hung-chang-dso-2100/api.c: In function ‘config_commit’:
../src/hardware/hung-chang-dso-2100/api.c:562:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
state = 0x01;
~~~~~~^~~~~~
../src/hardware/hung-chang-dso-2100/api.c:563:2: note: here
default:
^~~~~~~
../src/hardware/hung-chang-dso-2100/api.c:565:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (ret != SR_OK)
^
../src/hardware/hung-chang-dso-2100/api.c:567:2: note: here
case 0x01:
^~~~
../src/output/csv.c: In function ‘receive’:
../src/output/csv.c:580:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
*out = g_string_new(ctx->frame);
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
../src/output/csv.c:582:2: note: here
case SR_DF_END:
^~~~
../src/input/wav.c: In function ‘send_chunk’:
../src/input/wav.c:200:2: warning: ‘memset’ used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]
memset(fdata, 0, CHUNK_SIZE);
^~~~~~
../src/input/raw_analog.c: In function ‘init’:
../src/input/raw_analog.c:133:31: warning: ‘%d’ directive output may be truncated writing between 1 and 10 bytes into a region of size 6 [-Wformat-truncation=]
snprintf(channelname, 8, "CH%d", i + 1);
^~
../src/input/raw_analog.c:133:28: note: directive argument in the range [1, 2147483647]
snprintf(channelname, 8, "CH%d", i + 1);
^~~~~~
../src/input/raw_analog.c:133:3: note: ‘snprintf’ output between 4 and 13 bytes into a destination of size 8
snprintf(channelname, 8, "CH%d", i + 1);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The previous implementation used to provide datafeed packets which
contain logic data in positions that correspond to disabled channels.
Do mask out logic data of disabled channels in the memory image before
it is sent to the session's datafeed. This implementation works fine for
those situations where either all logic channels are enabled (default
configuration) or when only the upper channels get disabled (which can
be considered a typical use case).
For those configurations where enabled channels follow disabled channels
(i.e. setups with gaps in the sequence of enabled channels) behaviour
will be unexpected: Neither is the mask adjusted to contain gaps, nor
will enabled channels get mapped to result in a dense representation.
The respective code paths are marked with TODO comments.
Add a comment to discuss a non-obvious generator call for analog data in
the acquisition start routine, while we are here.
The generator logic determines how many samples per group (analog and
logic) need to get produced, then keeps iterating until each group has
reached the specified count. Different groups can generate different
numbers of samples per iteration, they have their own stride.
It's essential to check whether all channels in a group are disabled, to
then completely skip the respective half of the generation loop. Without
this check, the group would be expected to generate data but it won't,
which results in an endless loop. This was observed with analog channels.
There was another issue with logic channels. Unexpected logic data was
seen in the output although neither logic channel was selected.
This commit fixes bug #923.
Skip the emission of session datafeed packets for disabled analog
channels.
Implementation detail: Allow for quick lookup of the channel that is
associated with an analog generator, as the data generation routines
only pass generator references in later calls.
This fixes part of bug #923 (which initially is about unexpected
logic data while analog channels were affected in similar ways).
After the requested number of samples was sent, another session df
packet was emitted with one sample for the analog channels, which
contained the most recent result of averaging. Make this emission
depend on the "averaging requested?" flag.
This fixes bug #930.
The 'demo' driver supports scan options to adjust the number of
supported channels, and runtime control for the enabled state of
channels.
Starting with zero analog channels created (scan option) resulted in a
runtime assertion. Creating but disabling analog channels (GUI checkbox,
CLI option) resulted in unexpected output for disabled channels.
Move the creation of a hash table out of the conditional loop that
iterates over created analog channels. Which results in the table's
always being valid, and iteration during data acquisition yields no
analog output as is expected.
This fixes bug #625.
A previous implementation of the demo driver supported the creation of
larger channel counts yet only enabling part of them by default. This
was kind of pointless, I just was not aware of the available scan
options.
Drop the "enabled channels" limitation, enable all channels that get
created (like the implementation before the experiment did), and create
as many channels as was compiled in by default or later got specified
by scan options.
Before firmware upload some models (e.g. the original DSLogic or the
DSLogic Pro) don't have any USB manufacturer or product strings set, so
they wouldn't be detected.
Previously the USB communication code was split between api.ci,
dslogic.c and protocol.c, with protocol internals split between
both. This patch puts all the protocol handling code into one
source file reducing the number of internal interfaces and making
the code more readable.
Previously the USB communication code was split between api.c
and protocol.c, with protocol internals split between both. This
patch puts all the protocol handling code into one source file
reducing the number of internal interfaces and making the code
more readable.
Jan Luebbe
Gerhard Sittig
Uwe Hermann
Joel Holdsworth