| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
This shall support the original National LM75 I2C-based temperature sensor,
as well as various compatible devices of other vendors, such as the
Fairchild FM75, Dallas DS75, and so on.
Currently only 9bit resolution is supported, and not all commands are
decoded, yet. The register contents and temperatures are decoded
correctly though, and can be output in both Celsius and Kelvin.
|
|
Needed for g_get_monotonic_time(). Thanks to Tomaž Šolc.
|
|
The 'usb_signalling' decoder just decodes symbols from D+/D- levels,
handles bit stuffing and outputs the symbols and (potential) packets.
The 'usb_protocol' decoder takes that output and tried to parse USB
packets from it (SOF, SETUP, IN, OUT, DATA0, and so on).
This is the base decoder on top of which various others will stack
later on.
The two new PDs are work in progress, so we still keep the old 'usb' PD
around for a little while, until the two new ones are fully working and
well-tested.
|
|
This PD stacks on top of the UART protocol decoder, and ouputs the
decoded UART data in the "canonical" format, one byte after the other
without any metadata (start bits, stop bits, parity bits, errors) and
without any sample-numbers and such. This is basically what you would
see in a terminal program, such as minicom.
Per default it outputs to stdout, but using the 'filename' option
and/or the 'filename_rx'/'filename_tx' options it can also output to
files.
Using the 'tx' and 'rx' options you can also select whether both, or
only one of the data direction's data should be output.
Example:
sigrok-cli -i foo.sr \
-a uart:rx=0:tx=1,uart_dump:rx=no:tx=yes:filename=foo.txt \
-s uart,uart_dump
This PD is just an experiment for now, it's possible that it will be
replaced / reimplemented via a different sigrok facility later on.
|
|
|
|
|
|
|
|
Add ACLOCAL_DIR setting and AM_PROG_AR macro for compiling with Homebrew
under Mac OS X.
Applies essentially the same change to
{libsigrok,libsigrokdecode,sigrok-cli}/{autogen.sh,configure.ac}
It may be that the same fix is needed for the other autogen.sh and/or
configure.ac files, but that hasn't been tested and therefore not in
this commit.
|
|
(not yet finished)
This protocol decoder can decode ST STM32 specific JTAG accesses, knows
about the STM32-specific registers and bits.
|
|
This is unfinished, needs some more work.
|
|
Not quite finished yet, but relatively close.
|
|
This is unfinished and not tested, and probably not really working, yet.
|
|
|
|
|
|
No need to use the LIBSIGROKDECODE_ prefix here when we use SRD_ everywhere
else. Also, better distinction between package version and lib version.
|
|
|
|
The i2cdemux protocol decoder is the more generic version of the
obsolete ebr30a_i2c_demux decoder, and should be able (now or later) to do
everything that ebr30a_i2c_demux can do.
|
|
The next (and first) libsigrok release will be called 0.1.0.
The next (and first) libsigrokdecode release will be called 0.1.0.
The next sigrok-cli release will be called 0.3.0 (as we already had a 0.1
and 0.2 release of sigrok-cli; those did not yet use the libs, though).
sigrok-gtk and sigrok-qt didn't have any releases yet, so their version
numbers are set to 0.1.0.
Also, consistently use three numbers/digits for our version numbers.
|
|
|
|
|
|
|
