| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Drop checks where we don't use the result (yet). We might bring back
some of those once we start actually using the result in the code.
|
|
|
|
|
|
This is a temporary thing, later there'll be some facility to let
frontends handle any annotations marked as "this is a number" (as opposed
to "this is a string") in a generic manner and display them in any
supported (by that frontend) format, e.g. ascii, hex, oct, decimal,
binary, big-endian vs. little-endian, and so on.
This is a fix related to #201.
|
|
|
|
|
|
|
|
This fixes bug #175.
|
|
|
|
|
|
This fixes 'make install' and 'make dist' for out-of-tree builds.
|
|
|
|
|
|
|
|
|
|
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 decoder was just a simple test case for early libsigrokdecode
development and testing, it is neither useful nor properly working
currently, so drop it.
|
|
The functionality of the preliminary 'uart_dump' PD is now available
in the proper 'uart' PD, via the OUTPUT_BINARY mechanism that frontends
can use to dump decoded data (in various formats) to a file, or pipe it
into other applications, and so on.
Old sigrok-cli example usage:
$ sigrok-cli -i foo.sr -P uart:rx=0:tx=1,uart_dump:filename=bootlog.txt
New sigrok-cli example usage:
$ sigrok-cli -i foo.sr -P uart:rx=0:tx=1 -B uart=rxtx > bootlog.txt
New sigrok-cli example usage (piping into other applications):
$ sigrok-cli -i foo.sr -P uart:rx=0:tx=1 -B uart=rxtx | grep "whatever"
|
|
The functionality of the preliminary 'i2s_dump' PD is now available
in the proper 'i2s' PD, via the OUTPUT_BINARY mechanism that frontends
can use to dump decoded data (in various formats) to a file, or pipe it
into other applications, and so on.
Old sigrok-cli example usage:
$ sigrok-cli -i 2ch-16bit-16khz.sr \
-P i2s:sck=0:ws=1:sd=2,i2s_dump:filename=foo.wav
$ aplay foo.wav
New sigrok-cli example usage:
$ sigrok-cli -i 2ch-16bit-16khz.sr \
-P i2s:sck=0:ws=1:sd=2 -B i2s=wav > foo.wav
$ aplay foo.wav
New sigrok-cli example usage (piping into other applications):
$ sigrok-cli -i 2ch-16bit-16khz.sr \
-P i2s:sck=0:ws=1:sd=2 -B i2s=wav | aplay -
|
|
We just use dummy/fake python3.pc files on Windows so that the usual
pkg-config mechanism works there as well.
|
|
Even when using pkg-config not all distro/platform specific issues are
transparent, unfortunately. On some systems the pkg-config file is
named "python3.pc" on others it's versioned, e.g. "python-3.2.pc".
See also: http://sigrok.org/wiki/Libsigrokdecode/Python
This should fix the build on e.g. FreeBSD, NetBSD, Mac OS X (some
versions), and possibly various Linux distros, e.g. Gentoo.
Also, drop manual AC_MSG_ERROR() and let PKG_CHECK_MODULES() output a
more verbose and standardized error message if Python 3 is not found.
|
|
When no CLK probe is supplied to this PD, handle any transition on
any of the supplied data probes as if there had been a CLK transition.
(based on a suggestion/patch by "bmx" from the #sigrok channel, thanks!)
|
|
The python3-config script reported "-lm" as linker option previously,
but we switched to using pkg-config (among other things for
cross-compile support) which doesn't report "-lm" though (this is a
common behaviour across multiple distros and OSes).
|
|
Using python-config does not work when cross-compiling, since it
can only be run on the host system.
|
|
This closes bug #156.
|
|
|
|
|
|
|
|
|
