Age | Commit message (Collapse) | Author |
|
|
|
|
|
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).
|
|
This fixes parts of bug #309.
|
|
This fixes parts of bug #309.
|
|
This fixes parts of bug #309.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also, provide all the required annotation classes for this to work
properly.
|
|
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.
|
|
|
|
|
|
The output type is now called OUTPUT_PYTHON, adapt all PDs to that.
|
|
|