../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:
^~~~
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.
Handle the case when the sample data memory was filled and has wrapped
around during acquisition. Download the respective part of the data
which is reliably available, only skipping a single 1KB row which might
contain either old or new data while it's not certain which it would be.
This will be essential when triggers later become available. Right now
it copes with user requests for sample counts that exceed the total DRAM
capacity. Instead the maximum available amount of data is provided.
Of course acquisition no longer gets stopped when the end of DRAM is
reached.
Correctly determine the size of a download chunk for the last DRAM row
that's involved in the recent data acquisition.
This commit is based on work done by jry@.
This addresses bug #838 (trailing garbage).
It's assumed that the previously downloaded excess data was "swallowed"
by the sample count enforcement logic that was applied earlier, so the
(remainder of the) issue could have gone unnoticed, unless some other
termination condition than sample count was used.
Configure the samplerate clock and channel count during acquisition
start in identical ways for 50MHz, 100MHz, and 200MHz modes.
This part was inspired by work done by jry@ yet was addressed in
different ways (no exception, do everything in every mode the same way).
Eliminate a portability issue in the previous implementation. Make sure
to send the configuration bytes in the correct order to the hardware.
Don't typecase a struct reference to a bytepointer and hope that the
internal memory representation might fit the external hardware's idea.
Add a comment about sample memory organization in a central spot. This
concentrates knowledge which otherwise would be spread across several
locations all over the driver's codebase, yet is essential to have at
hand during maintenance.
All of the information was determined/updated by jry@ with the help of
Ondrej at Asix when he did lots of fixes and improvements to asix-sigma.
The Asix Sigma hardware does not support a sample count limit. Instead
this optional input parameter gets mapped to a sample time, and some
slack for hardware pipelines and compression gets added. When data
acquisition completes and sample data gets downloaded, chances are that
there is more data than requested by the user.
Do enforce the optional sample count limit. Stop sending data to the
sigrok session when the configured number of samples was sent.
This commit is based on work done by jry@.
This fixes bug #838.
Uwe Hermann
Gerhard Sittig
Joel Holdsworth
Soeren Apel