| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is not yet finished, more things should be made private.
|
|
|
|
|
|
|
|
|
|
|
|
|
