Uwe Hermann [Sun, 4 May 2014 21:14:25 +0000 (23:14 +0200)]
Update the manpage.
- Don't refer to the not yet existing nexus-osciprime driver.
- Update an example sigrok-cli --scan output to match the current format.
- Update some sections to honor that channels are now specified by
name (not number). Example: "-P uart:rx=FTDIRX" instead of "-P uart:rx=6"
(if channel 6 has been actually named "FTDIRX" by the user/frontend).
This fixes bug #332.
- SPI PD: The 'sck' pin is now called 'clk', update the manpage example.
- Fix a typo in the -S documentation: s/-A/-P/.
- The --time option currently only supports "ms" and "s" as units.
Uwe Hermann [Sat, 12 Apr 2014 11:42:30 +0000 (13:42 +0200)]
Rename 'probe' to 'channel' (libsigrokdecode change).
The -p|--probes option is renamed to -C|--channels.
Variables of type 'struct srd_channel *' are consistently named 'pdch' to
make them easily distinguishable from libsigrok's 'struct sr_channel *'
variables that are consistently named 'ch'.
Uwe Hermann [Tue, 11 Mar 2014 22:43:20 +0000 (23:43 +0100)]
nsis: Fix the "working dir" path for sigrok-cli.
For now, start the "DOS box" in the sigrok-cli installation directory,
so that the firmware files and decoder files are found correctly.
We'll probably use another solution that sets %PATH% later on, though.
Thanks to Peter Newman for bringing up this issue.
Uwe Hermann [Tue, 11 Mar 2014 21:09:53 +0000 (22:09 +0100)]
nsis: contrib/sigrok-cli.nsi.in: Drop obsolete file.
We're only using the cross-compile version sigrok-cli_cross.nsi.in these
days since it is much more convenient, and the old native build file
was not working and/or up-to-date anyway.
Dan Horák [Sat, 25 Jan 2014 13:15:24 +0000 (14:15 +0100)]
fix build without libsigrokdecode
When built with libsigrokdecode additional headers are automagically included
via the Python.h header. When built without they must included explicitly.
Uwe Hermann [Tue, 19 Nov 2013 10:48:06 +0000 (11:48 +0100)]
Fix a bunch of compiler warnings.
We need to ensure that libsigrokdecode.h is always the first #include,
otherwise some versions of Python will cause all kinds of compiler
warnings like these:
CC device.o
In file included from /usr/include/python3.2mu/Python.h:8:0,
from [...]/include/libsigrokdecode/libsigrokdecode.h:25,
from sigrok-cli.h:26,
from device.c:23:
/usr/include/python3.2mu/pyconfig.h:1182:0: warning: "_POSIX_C_SOURCE" redefined [enabled by default]
#define _POSIX_C_SOURCE 200112L
^
In file included from /usr/include/limits.h:26:0,
from /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/limits.h:168,
from /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/syslimits.h:7,
from /usr/lib/gcc/x86_64-linux-gnu/4.8/include-fixed/limits.h:34,
from /usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h:11,
from /usr/include/glib-2.0/glib/gtypes.h:34,
from /usr/include/glib-2.0/glib/galloca.h:34,
from /usr/include/glib-2.0/glib.h:32,
from device.c:21:
/usr/include/features.h:231:0: note: this is the location of the previous definition
# define _POSIX_C_SOURCE 200809L
^
Since sigrok-cli.h already #includes libsigrok.h and libsigrokdecode.h,
just ensure that the latter is always the first #include by _only_
including it in sigrok-cli.h and nowhere else.
sigrok-cli: Fix memory leak if we save the default output format to a file.
g_free_byte_array accepts as the second argument a gboolean which determines if
the actual byte data should also be freed:
https://developer.gnome.org/glib/2.28/glib-Byte-Arrays.html#g-byte-array-free
If we pass a FALSE here the data should be freed with g_free(), instead just
pass TRUE and the data will be automatically freed.
Bert Vermeulen [Sun, 10 Nov 2013 11:50:52 +0000 (12:50 +0100)]
Show only one output type at the same time.
OUTPUT_BINARY takes precedence if specified, and is always output
'raw', without extra information, so it can be piped into other programs.
Otherwise, if specified, OUTPUT_META is shown. If none of these is
specified, the default is to show OUTPUT_ANN (all classes) of the
top PD in the stack.
Bert Vermeulen [Sat, 2 Nov 2013 21:44:14 +0000 (22:44 +0100)]
New --probe-group option
Devices that don't use probe groups don't need this option at all;
it only needs to be specified when using a device that has probe
groups, and then only for options that require it.