| Age | Commit message (Collapse) | Author |
|---|
|
srd_inst_new() used the decoder ID as the instance ID, preventing the use
of multiple instances of the same decoder in the same session. Simply
append a numerical suffix to later instances to allow more.
Required changes to cleanup to reliably free all memory. Valgrind checked.
This fixes parts of bug #868.
Based on original work by: Soeren Apel <soeren@apelpie.net>
Signed-off-by: Karl Palsson <karlp@etactica.com>
|
|
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.
|
|
Old versions triggered valgrind errors as the API method to remove an
entry modifies the list that was being iterated.
Signed-off-by: Karl Palsson <karlp@etactica.com>
|
|
Several checks get applied when loading externally provided protocol
decoders. Print error messages when checks fail, so that developers can
better resolve issues.
The sequence of tests terminates upon the first failed check, while
decoders may suffer from several issues at the same time. This is
considered acceptable, as it reduces the commit's size and the code's
complexity. This commit only adds error messages, and does not change
logic/behaviour.
Failed API version checks result in two messages: One specific message
which reflects the decoder's version and what's supported by the loader,
and a generic message that the API version check has failed. This is
done to simplify the logic of a rarely used error code path.
This commit addresses libsigrokdecode Bug 704, and allows to identify
decoders from parallel installations of differing version.
This fixes bug #704.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
|
|
|
|
This issue was discovered via the newly added unit tests.
|
|
Create a utility function for loading a Python module by its name
in UTF-8.
|
|
|
|
Limit usage of the Python C API to the stable ABI subset as defined
by PEP 384. This removes some type definitions and functions which
libsigrokdecode made use of. Convert all affected code to suitable
API alternatives. Also fix a few leaks that became apparent while
working on the code.
The most visible change is that PyTypeObject is now an opaque type.
Thus, the custom Decoder and srd_logic types are now created on the
heap via an alternative API. Unfortunately, since tp_name is now
inaccessible, type names had to be removed from the log output.
Stack traces after Python exceptions are now formatted by calling
into Python, since the trace object C API is no longer available.
|
|
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
|
|
|
|
Use g_malloc*() for small allocations and assume they always
succeed. Simplify error handling in a few places accordingly.
Document the rules in the README file.
|
|
This fixes bug #378.
|
|
This prevents Python.h from being included into client code, where
it can mess things up by e.g. redefining _POSIX_C_SOURCE.
|
|
srd_decoder_load() works perfectly with decoders stored inside zip files.
However, srd_decoder_load_all{_path,}() did not, because it assumed that
normal directory listings can be used to enumerate decoders, which is not
the case for zipped decoders. Fix this by providing a fallback based on
the zipimporter Python class.
|
|
Decoders that implement any other PD API version are per definition not
compatible and cannot work with this library version.
|
|
|
|
|
|
The function srd_check_init() is only used in decoder.c.
|
|
|
|
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'.
|
|
|
|
Annotation entries also consist of a tuple, not a list.
|
|
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.
|
|
|
|
|
|
srd_decoder_load_all() was really only getting a list of decoders
from the default (installation) path, so could not find uninstalled
decoders, or those in a custom added search path.
This broke development of new PDs when using the SIGROKDECODE_DIR
environment variable, and broke many of the unit tests in the tests/
directory -- those actually tested against the already-installed
decoders, not the ones about to be installed.
|
|
|
|
|
|
Python silently uses the existing module anyway, but the library
was counting it as an extra module. This was exposed by a test
case in the test suite.
|
|
This fixes bug 177.
|
|
|
|
This requires the PD to have a tuple in its class called 'binary',
which contains a list of strings describing the different binary
classes it can output. For the SPI decoder this might be 'MOSI' and
'MISO', for example.
The data is submitted to the frontend as struct srd_proto_data_binary,
which contains the class that data belongs to.
|
|
|
|
The struct srd_session also holds configuration parameters formerly
passed to srd_session_start().
The new call srd_session_new() takes a pointer where a newly allocated
pointer to struct srd_session will be stored. This pointer must be
passed as the first argument to all functions that require it.
The SRD_CONF_NUM_PROBES, SRD_CONF_UNITSIZE and SRD_CONF_SAMPLERATE
keys must be configured with srd_config_set() before srd_session_start()
is called.
A new call srd_session_destroy() is also available. This cleans up all
resources the session holds. This is also called from srd_exit() for
all sessions.
|
|
|
|
|
|
|
|
This matches the convention used in libsigrok. Potential other headers
might end up in libsigrokdecode/, but only libsigrokdecode.h is meant
to be #included by frontends directly.
|
|
Also, document the functions in version.c.
|
|
|
|
Decoder options are now exposed in struct srd_decoder, via a GSList
of the new struct srd_decoder_option. The 'def' field represents
the default value as set in the decoder, converted to GVariant. This
allows a library user to determine the type as well as default value.
|
|
|
|
These short descriptions are shown in the "Files" section of the
Doxygen output.
|
|
|
|
|
|
The upcoming libsigrokdecode release should not contain any API changes
so it is compatible with existing released frontends (sigrok-cli 0.3.1).
|
|
|
|
In the protocol decoder you always get all required probes, then _all_
optional probes in the list of probes in the decode() call.
Example:
(r1, r2, r3, o1, o2, o3, o4) = pins
In this case r1-r3 are required probes, o1-o4 are optional probes.
However, the value of valid/used/specified probes will be 0 or 1,
whereas the value of probes that were not specified/assigned by the user
will be (at the moment) 42.
The PD can check for a valid probe like this:
if p in (0, 1):
...
Or check for an invalid probe:
if (p > 1):
...
The value of 42 could change to be -1 or None later.
|
