| Age | Commit message (Collapse) | Author |
|---|
|
Sometimes the Python 3 executable is called just 'python3', sometimes
it is called 'python3.4' and so on. Handle all cases transparently for
the user.
Before:
$ make install
/usr/bin/env: python3: No such file or directory
After:
$ make install
python3.4 ./tools/install-decoders -i ./decoders -o [...]
Installing 36 protocol decoders:
[...]
|
|
|
|
(fewer files, less clutter)
|
|
Also, drop printing of the detected Python CPPFLAGS/LDFLAGS, not really
needed since it's available in 'make V=1' output as well (and we don't print
it for other libs either).
|
|
We use some functions specific to 3.1, but every distribution appears
to be at 3.2.x already anyway.
|
|
|
|
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.
|
|
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.
|
|
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 only compiles libsigrok into the one target that needs it, instead
of slopping it all over the place.
|
|
This adds a tool in the tests directory, called pdtest. It uses the
"test/" directory in every PD directory, if present, to run the
PD against dumps found in the sigrok-dumps repository, and compares
the output against ".output" files in the "test/" directory. The file
"test/test.conf" is used to configure which tests to run.
A separate tool (tests/runtc.c) is used to run the actual decoding and
report output.
To get an overview of the options, run tests/pdtest without any options.
|
|
|
|
|
|
This PD tries to guess / detect / estimate a bitrate of e.g. some
UART communication snippet or other protocols.
|
|
|
|
This uses the Check unit testing framework, just like libsigrok.
For now, only a few very basic unit tests are included.
Invocation:
make check
|
|
This stacks of top of the 'i2s' decoder and outputs the audio data to
file (or stdout) in various formats. Currently only WAV is supported.
This is work in progress, it has various hard-coded assumptions.
|
|
There will be further PDs that are stacked on top of usb_packet.
|
|
This supports a certain number of MIDI messages already, but not yet all
of them. More will be added later.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
The automake 'std-options' option checks whether all installed tools
and scripts have a --help and --version CLI option. This check is not
needed for libsigrokdecode though, since it doesn't install any tools.
|
|
Dallas DS1307 RTC protocol decoder that works stacked
with the I2C PD. Based on the rtc8564 protocol decoder.
Signed-off-by: Matt Ranostay <mranostay@gmail.com>
|
|
This is used in the generated Doxygen HTML output.
|
|
|
|
The last release of libsigrokdecode (package version number 0.1.0) had the
initial libtool version numbers (current:revision:age) of 0:0:0.
The upcoming release (0.1.1) is API-compatible with 0.1.0 and can be used
as drop-in replacement. Programs linked against 0.1.0 do not need to
be recompiled or relinked.
As per the libtool guidelines this release only increments the
libtool "revision" number. The new libtool version numbers
(current:revision:age) are thus 0:1:0.
See here for details:
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
|
|
- Don't use "foreign" option for automake. Without this automake will
perform some additional sanity checks e.g. on missing files. It will also
now add the usual INSTALL file which documents the configure options etc.
- Add AUTHORS file.
- Add 'check-news' automake option, which will abort 'make dist' if
the NEWS file doesn't list the current (to be released) package
version at the top (i.e., if we forget to update NEWS).
|
|
We don't need a C++ compiler for libsigrokdecode, so don't check for one.
This would cause a build failure on all systems where there is a C compiler
but no C++ compiler installed.
|
|
We don't use any of the recent glib features in libsigrokdecode, it
compiles fine with 2.24.x.
|
|
|
|
|
|
Don't override/overwrite CFLAGS in configure.ac, but rather amend it
with (currently) "-Wall -Wextra".
This properly allows users/packagers to do things like:
./configure (this will default to using "-g -O2" additionally)
CFLAGS="-g -O2" ./configure (same as above)
CFLAGS="" ./configure (no additional flags)
CFLAGS="-g -O0" ./configure (disable optimization, e.g. for valgrind use)
etc. etc.
|
|
|
|
|
|
|
|
|
|
On Windows, cmake-using projects seem to have problems with the
"-I/c/Python32/include" syntax we have in the libsigrokdecode .pc file.
However, "-Ic:/Python32/include" works fine. So we just add both to
support everything.
|
|
This is work in progress, but it already works partially, and can be used
for actual decodes of some commands.
This PD stacks on top of the SPI protocol decoder.
|
|
|
|
It doesn't make sense to have one "generic" onewire_transport PD, as
this layer is very much device-specific and such a generic PD would
have to contain an accumulation of all possible features and commands
and handling code of all existing (now and in the future) 1-Wire
devices, which is neither possible nor useful nor elegant.
There are (for example) 1-Wire thermometers, RTCs, EEPROMs,
special-purpose security chips with passwords/keys, battery monitoring
chips, and many many others. They all have a different set of features,
commands and command codes, RAM areas/sizes/partitioning/contents,
protocols, and so on.
Thus, the layering for 1-Wire PD stacks should look like this:
onewire_link -> onewire_network -> <specificdevice>
Examples:
onewire_link -> onewire_network -> maxim_ds28ea00 (special thermometer)
onewire_link -> onewire_network -> maxim_ds2431 (1kbit EEPROM)
onewire_link -> onewire_network -> maxim_ds2417 (RTC)
onewire_link -> onewire_network -> maxim_ds2762 (battery monitor)
onewire_link -> onewire_network -> maxim_ds1961s (SHA-1 eCash iButton)
and so on...
So, renaming onewire_transport to maxim_ds28ea00. The non-DS28EA00
specific code will be dropped and/or moved to other PDs on top of
onewire_network later.
|
|
|
|
|
|
The new 'usb_signalling' and the 'usb_protocol' PD which stacks on top
of it, replace the old 'usb' decoder.
|
