| Age | Commit message (Collapse) | Author |
|---|
|
This uses a template generated by Doyxgen 1.8.1.2 (like libsigrok
currently does) and adapts it to libsigrokdecode needs.
|
|
|
|
|
|
|
|
|
|
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).
|
|
The upcoming libsigrokdecode release should not contain any API changes
so it is compatible with existing released frontends (sigrok-cli 0.3.1).
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Thanks Iztok Jeras <iztok.jeras@gmail.com> for the report.
|
|
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.
|
|
The temperature unit is nowadays called just "Kelvin", not
"degrees Kelvin" (even though this was not always the case).
|
|
|
|
|
|
|
|
While states in the PD should be ALLCAPS per guidelines (for
consistency), the annotations that a PD outputs (and are shown in a
console via sigrok-cli or in a GUI) should be "normal" human-readable
text/formatting usually, i.e. not ALLCAPS.
|
|
|
|
|
|
|
|
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 'Overdrive match ROM' command is 0x69, not 0x6d. Verified in various
datasheets and the original 1-Wire/iButton spec.
|
|
The annotation types are 'Text' and 'Warnings', not 'Link' etc. as the
annotations of the onewire_link PD (for example) are already clearly
from the link layer. The annotation types should be different things/formats
of a specific PD's annotation output instead (like "Celsius" / "Kelvin"
for some temperature sensor, for example).
|
|
Also, some additional cleanups.
|
|
|
|
|
|
|
