| Age | Commit message (Collapse) | Author |
|---|
|
Add the __declspec(dllexport) decoration to SRD_API routines on Windows
when building the library body (this is new). Stick with the default
visibility on all other platforms (as previously implemented).
This is similar to what Kyle Johnson submitted in PR 66, but phrased
differently. Avoid the non-portable indentation before the hash in
preprocessor instructions. Use positive logic for readability (put
the Windows branch next to the check for the Windows platform).
Reported-By: Kyle Johnson <KyleJ61782@gmail.com>
|
|
Introduce the public srd_session_send_eof() routine which is backed by
the internal srd_inst_send_eof() helper. Applications can tell decoders
when the input stream of sample data is exhausted, so that decoders can
optionally "flush" their previously accumulated information when
desired. Previous implementations just kept decoders in blocking .wait()
calls and somehow terminated them at arbitrary times afterwards.
When EOF is sent to the decoder session, then calls to the .wait()
method which typically are done from .decode() or its descendents will
end with an EOFError Python exception. Termination of .decode() with the
EOFError exception is non-fatal for backwards compatibility and to keep
the convenience for current decoder implementations. Decoders can either
catch the exception, or use context managers, or do nothing.
This API extension is motivated by research for bug #1581 and provides
the infrastructure to address bug #292. Decoders need to remain careful,
and should not claim that protocol activities would have completed when
their end condition was not even seen in the capture. Marking incomplete
activities with warnings is the most appropriate reaction.
|
|
|
|
|
|
This means that the samplerate for logic output channels is
implicitly determined by the input channel samplerate.
The motivation for this is that hard-coding a samplerate isn't
possible - but at the same time, it's also not possible to
determine the samplerate at the time the logic output channels
are initialized, as the samplerate can be set at runtime.
From my point of view, we would need one of two mechanisms to
make this work:
1) Allow creation of logic outputs at runtime via some
registration callback
or
2) Allow changing a logic output's samplerate after it has been
created, again requiring some kind of callback
To me, both currently are overkill because making the assumption
that samplerate_in = samplerate_out not only makes this problem
go away as it can easily be handled on the client side where
samplerate_in is already known, it also makes handling of the
logic data in the PDs easier.
|
|
Protocol decoders can now declare an arbitrary number of logic output
channels with a fixed assumed samplerate each.
|
|
|
|
|
|
Allow applications to query the currently registered log callback. So
they can either restore the previously registered routine, or register
another routine _and_ log to the previously registered routine as well.
|
|
|
|
The previous implementation internally noticed the "want terminate"
request, and skipped decoder execution to faster get to the end of the
input stream. But an OK return code was provided in that code path, and
more input data was sent by applications (sometimes for many seconds or
few minutes).
Do return a new SRD_ERR_TERM_REQ error code, such that applications can
tell failed execution from requested termination.
|
|
Implement routines which terminate currently pending decoder operations
and reset internal state (on the C and Python sides) for instances as
well as sessions. This allows to re-use previously created stacks for
new input data.
|
|
As this uses g_slist_copy_deep(), we now require glib 2.34.
|
|
This allows frontends to set the assumed initial pins (i.e., the assumed
state of the pins before the first sample of a capture) to user-specified
values.
The assumed initial pins can be either low, or high, or "use same value
as the first sample of the capture".
The special self.initial_pins decoder attribute is now removed.
|
|
|
|
|
|
Add support to terminate blocking .wait() and .decode() method calls of
v3 decoder instances. This terminates the decoder thread's main routine
and allows to release associated resources. Cope with requested as well
as unexpected termination of decode() calls. Add debug messages to
thread related code paths.
Make sure to unblock the main thread which feeds the decoder thread.
This unbreaks situations where decoders e.g. throw "need samplerate to
decode" exceptions.
Drain Python errors which might remain from the most recent .decode()
execution, to not affect other code paths. This avoids an issue where
the creation of a new decoder instance fails in the presence of errors
from a previous run.
This fixes bug #902.
|
|
|
|
Remove the FSF postal address as it might change (it did in the past).
Reference the gnu.org website instead which is more stable.
|
|
For the time being, both APIs (2 and 3) will remain supported until all
decoders have been converted to API version 3. Then, support for API
version 2 will be dropped.
Decoders using PD v3 API can benefit from both readability improvements
as well as performance improvements. Up to 10x speedup has been measured
in some situations (depends a lot on the decoder, the amount of data,
the amount of edges in the signals, the amount of oversampling etc. etc.).
This is only the first set of (basic) performance improvements for
libsigrokdecode, there are various additional opportunities for further
changes to improve performance.
This changeset has been tested to survive a run of all the test-cases in
the sigrok-test repo without issues (for the converted PDs), however it is
not very well-tested yet, so there might be regressions that need to be
addressed.
|
|
The confusingly named srd_log_logdomain_set() simply set a global
string prefixed to the log message by the default log callback.
This is pretty much useless, misleadingly named, and not used by
either sigrok-cli or PulseView.
|
|
Don't pass unitsize to srd_inst_channel_set_all(), have that only
set the channel map. Instead, srd_session_send() now has a parameter
for the unitsize which is passed with every new chunk to be decoded.
This is in preparation to fix issues with devices or files which
have a unitsize != 1 and where the "guessed" unitsize based on the
number of channels is not correct.
This also allows for (potential) future changes where every chunk can
indeed have a different unitsize.
This fixes (parts of) bug #352.
|
|
The naming has been changed to "annotation class" a while ago.
|
|
|
|
This prevents Python.h from being included into client code, where
it can mess things up by e.g. redefining _POSIX_C_SOURCE.
|
|
This matches the libsigrok conventions, and will be required (or
at least nice to have) for libsigrokdecode language bindings later.
|
|
It's not public API and is not used (nor should it be used) by any frontends.
|
|
Avoid defining any names ending in _t, those are generally reserved
for POSIX usage. For details see:
http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh_chap02_02.html
http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html
|
|
Variables of type 'struct srd_channel *' are consistently named 'pdch' to
make them easily distinguishable from libsigrok's 'struct sr_channel *'
variables that are consistently named 'ch'.
|
|
Each option consists of a dictionary with the following keys:
id The option id, which is passed in when setting a value.
desc A description of the option, suitable for display.
def The default value for this option.
values (optional) If present, a tuple containing values the option
may take. They must be of the same type as the default.
Valid types for the options are UTF-8-encoded strings, integers, and
floating point values.
|
|
|
|
An annotation row is a list of annotation classes that should all be
displayed in the same "row" in GUIs.
For example, the UART decoder would have at least two rows (for decoded
RX and TX data/startbits/stopbits/paritybits), the SPI decoder would have
at least two rows (for decoded MISO and MOSI data), and so on.
Each annotation row has a short ID string (mostly for use in
command-line frontends), a description string (mostly for use by GUIs),
and a tuple/list of annotation class IDs belonging to this row.
If no annotation rows are provided by the decoder, frontends can
consider this as the "trivial" case of all annotation classes being
displayed on the same (only) row.
|
|
Fixes bug 120.
|
|
|
|
|
