| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Older libsigrokdecode versions are no longer able to use the current
versions of the PDs (various changes in syntax etc).
|
|
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.
|
|
This fixes the data/annotations of stacked PDs.
|
|
|
|
This makes things a bit easier/clearer for most stacked PDs.
|
|
|
|
|
|
|
|
|
|
|
|
This can be used by higher-level PDs to decode per-bit items (not just
based on whole datawords).
|
|
|
|
|
|
The output type is now called OUTPUT_PYTHON, adapt all PDs to that.
|
|
|
|
|
|
|
|
This fixes bug #175.
|
|
|
|
|
|
The single comment re-stating the PD's name / description / purpose in
each pd.py file is not really needed, that info is available in the
Decoder class' attributes already.
|
|
|
|
This automatically figures out the files to install for each protocol
decoder, without involving autotools.
All python files (filenames ending in .py) are always installed. If a
protocol decoder requires installation of a non-python file, a small
file called 'config' can be created in that protocol decoder's
directory, with the following content:
# comments are ok
extra-install vendorlist.txt commands.txt
|
|
|
|
|
|
|
|
This better reflects what it is: a python object generated and
processed by python code.
|
|
|
|
Add a short help text for the PD and move the OUTPUT_PROTO docs to pd.py
since they're not meant for the user too see.
|
|
The CS# pin is now optional, it can either be supplied to the PD or not.
If it _is_ supplied, reset the PD state every time it changes. This has
the effect that "incomplete" SPI frames and those where CS# is not
asserted are ignored and not decoded.
This fixes bug #152.
|
|
|
|
For now SPI gets the following annotation types:
- MISO/MOSI SPI data
- MISO SPI data
- MOSI SPI data
(i.e. you can see either MISO, or MOSI, or both; the latter is most
useful for CLI usage)
Also, show the hex values as e.g. F5 (upper-case letters, no "0x" prefix).
|
|
This now makes the SPI decoder suitable for use in GUIs.
This fixes bug #150.
|
|
The data format can be specified via the PD's "format" option now, it is
no longer an annotation type.
Also, add and use two annotation types: "Data" and "Warnings".
|
|
|
|
The Python module name is determined by the directory name (e.g. dcf77),
the *.py file names in that directory don't matter and can be kept
consistent.
|
|
Ignore/skip identical samples in most (low-level) PDs, as we're usually
(but not necessarily always) only interested in pin changes.
This yields a significant performance improvement for the PDs.
The mechanism was already used in the 'i2s', 'jtag', and 'lpc' PDs, but not
yet in all supported low-level decoders. The following PDs now also use
this mechanism: 'dcf77', 'i2c', 'spi', 'uart', and 'usb_signalling'.
Thanks Lars-Peter Clausen <lars@metafoo.de> for bringing this to our
attention.
|
|
|
|
As per guidelines in HACKING, the protocol "commands"/items should be ALLCAPS,
thus change 'data' to 'DATA'. Also, fix MX25Lxx05D protocol decoder
accordingly, currently the only one we have which stacks on top of SPI.
Add a new 'CS-CHANGE' output protocol item, which is sent upon every
change of the CS# pin value (either 0->1, or vice versa). This is needed
by various higher-level PDs.
|
|
|
|
|
