Passing segment instances fails because this creates a race condition.
When a long conversion is taking place, the SignalBase::samples_added
signal is called often but since it's in a separate thread, the calls
are queued and aren't executed immediately. Now if the conversion is
restarted - for example as a result of a changed conversion threshold -
then the segments holding the converted data are destroyed, rendering
the pointers submitted as parameters to samples_added invalid.
Once the signal queue is processed, those invalid pointers will be
accessed and PV segfaults.
Since the signal queue can neither be emptied nor flushed, this
leaves only two sensible choices:
1) Signal samples_added less often, thereby reducing the chance of
signals being queued
2) Supply the segment ID instead of the segment instance as that's
essentially the only thing we currently care about - in fact, the
only user of samples_added (ViewBase::on_samples_added) uses the
instance to query only this
As #1 is only a band-aid and not a waterproof solution, I chose
to go with #2.
As reported in bug #1118 not all input sources provide a samplerate, and
decoder instances may not cope with a rate spec of 0. Only pass non-zero
sample rates to the decoder stack. This improves robustness in addition
to the specific fix for #1118 in the decoders' implementations.
Use case is as follows:
- Capture 20+ segments with ~500kS each
- Afterwards, enable conversion for a channel
Without this change, the converted logic will be repainted
20++ times because we are only told that new samples were
added but not which segment.
With this change, the logic trace is only painted when we
see that samples were added to the segment we're showing.
Instead of terminating, we wait instead.
We do this because SignalBase::on_samples_added() somehow doesn't
reliably see that there's no conversion thread active anymore.
conversion_thread_.joinable() returns true when the thread was
already terminated for whatever reason, resulting in on_samples_added()
trying to notify a non-existant thread.
Instead of handling the metadata separately from the mux/decode segments,
it's much neater to handle both together. Doing this also allows us to
remove the need for query_input_metadata() since we're taking the metadata
from the muxed logic segments.
When assigning the decoder stack channels to the libsrd
instance's channels, channels that had no signal assigned
to them were still assigned anyway. This patch fixes this bug.
After doing this, another subtle bug became apparent:
The mapping between channels and bits in the data stream sent
to the PD was done via DecodeChannel->id. This is however
insufficient as the channels of the decoder stack have
IDs that may or may not match the ID needed for the data
stream. Example:
A PD has 4 channels: A, B, C and D. In PV, those channels
have the IDs 0, 1, 2 and 3. If the user only assigns A and D,
Decoder::create_decoder_inst() will use the IDs 0 and 3 as
the bit positions of those signals in the data stream sent
to libsrd. This is obviously wrong.
Hence, we now use a separate bit_id for this purpose.
The reason for this change is that when you initially select a
conversion from the channel config popup dialog, the threshold
will be set to "0.0V" or "0.0V/0.0V", respectively.
This is of course not what we want and the root cause is that
when no preset is selected, NoPreset is assumed instead of
DynamicPreset. This patch changes this.
This way, we can use the same mechanism for changing
min/max as well, preventing multiple successive starts
of the conversion algorithm.
Preventing this is necessary because it makes the UI
stop updating for a significant amount of time, which
we obviously don't want.
The thought behind this was to have no unnamed signals because
this may make debugging harder. However, giving the signal a
long name and shortening it when decoders are added isn't working
well. The reason is that the width of the header area can be
expanded programmatically but we don't shrink it because we
don't want to hide things the user may want to see.
This behavior in turn leads to the header width expanding when
a signal labeled "Empty decoder signal" is added, only to see
this very signal be renamed to e.g. "SPI" immediately afterwards.
As we don't shrink the header width, the header is now too wide.
This patch was generated using clang-tidy:
clang-tidy -checks="-*,..." -fix
The following set of checks was enabled:
modernize-use-nullptr,modernize-deprecated-headers,modernize-make-shared,
modernize-redundant-void-arg,modernize-use-bool-literals,
modernize-use-emplace,modernize-use-equals-default,
google-readability-namespace-comments,misc-unused-using-decls
Add NOLINT to have clang-tidy (among other tools) ignore some lines
that are not meant to be changed.
Currently, the thresholds are determined by the minimum
and maximum values of a signal. From those, we derive the
high and low thresholds by using a 10% margin to min/max.
However, this approach doesn't work very well when the
measurement includes reset conditions or similar, causing
spikes that raise the min/max significantly.
Example:
sigrok-dumps/i2c/eeprom_24xx/microchip_24lc64/sainsmart_dds120_powerup_scl_sda_analog.sr
This patch changes the thresholds margins to 35%. However,
they are expressed differently: (max-min)/2 is used as the
center line, from which 15% of the amplitude (max-min) is
used as the margin. This way seems a little more intuitive
for me since the percentage given (15) is directly proportional
to the hysteresis.
Until now, Segment::get_raw_samples() was allocating the required
amount of memory and returned it to the caller to use. This way,
there was always enough memory allocated for the data that was
written to that memory location.
However, in SignalBase::conversion_thread_proc() we want to use
one memory location multiple times because we will create several
layers of libsigrok wrapper objects around it. This only works
if Segment::get_raw_samples() uses a given memory location instead
of allocating it by itself.
Soeren Apel
Gerhard Sittig
Philipp Marek
Uwe Hermann