Uwe Hermann [Wed, 21 Nov 2012 21:43:02 +0000 (22:43 +0100)]
All PDs: Name the files pd.py consistently.
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.
Uwe Hermann [Sat, 21 Jul 2012 19:58:20 +0000 (21:58 +0200)]
srd: onewire_link: Annotations shouldn't be ALLCAPS.
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.
Uwe Hermann [Sat, 21 Jul 2012 18:37:41 +0000 (20:37 +0200)]
srd: Rename onewire_transport to maxim_ds28ea00.
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:
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.
Uwe Hermann [Sat, 21 Jul 2012 17:16:16 +0000 (19:16 +0200)]
srd: onewire_link/network: Fix annotations, small cleanups.
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).
Uwe Hermann [Wed, 11 Jul 2012 20:19:31 +0000 (22:19 +0200)]
srd: Performance improvements for various PDs.
Ignore/skip identical samples in most (low-level) PDs, as we're usually
(but not necessarily always) only interested in pin changes.
This yields a significant performance improvement for the PDs.
The mechanism was already used in the 'i2s', 'jtag', and 'lpc' PDs, but not
yet in all supported low-level decoders. The following PDs now also use
this mechanism: 'dcf77', 'i2c', 'spi', 'uart', and 'usb_signalling'.
Thanks Lars-Peter Clausen <redacted> for bringing this to our
attention.
Uwe Hermann [Thu, 28 Jun 2012 19:43:12 +0000 (21:43 +0200)]
srd: i2cfilter: Output actual I2C packets.
Change this PD from an I2C->databytes converter/filter to an actual
pure I2C filter in the sense that both input and output is a valid I2C
protocol stream.
Also, change the EDID decoder accordingly, to use the new i2cfilter
output.
Uwe Hermann [Wed, 27 Jun 2012 18:02:25 +0000 (20:02 +0200)]
srd: Add National LM75 protocol 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.
Uwe Hermann [Tue, 19 Jun 2012 15:29:18 +0000 (17:29 +0200)]
srd: Split USB decoder in two PDs (which stack).
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.
Uwe Hermann [Fri, 15 Jun 2012 13:21:06 +0000 (15:21 +0200)]
srd: usb: Add long description of the PIDs.
Also, add missing ones which are mentioned in the USB spec. However, not
all may be relevant for LS/FS signalling. But they're still useful to
have in the table, so we can output warnings like
"Warning: HS PID encountered, but device is FS???"
Uwe Hermann [Thu, 14 Jun 2012 20:46:52 +0000 (22:46 +0200)]
srd: usb: Preliminary USB low-speed support.
Some of the differences of USB low-speed (compared to full-speed) are:
- 1.5Mb/s datarate, not 12MBit/s.
- The J and K states are swapped/inverted.
Note: This is work in progress, further changes may still be needed.
Add a 'signalling' option, which allows the user to select whether the
PD should decode using the low-speed or full-speed signalling protocol.
If unspecified, the default is full-speed.
Uwe Hermann [Thu, 14 Jun 2012 00:02:42 +0000 (02:02 +0200)]
srd: uart_dump: Fix file output (flush).
We need to flush the file output buffer(s), lacking a stop() call in
PDs at the moment, which could do the flush (or file close()) only once
at the end of the PD "session".
Uwe Hermann [Wed, 13 Jun 2012 23:14:10 +0000 (01:14 +0200)]
srd: Add experimental uart_dump decoder.
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.
Uwe Hermann [Sun, 27 May 2012 14:15:06 +0000 (16:15 +0200)]
srd: nunchuk: Fix most annotation samplenumbers.
Also, add a self.putx() helper method, as most annotations we have right
now are exactly one I2C packet long (there will also be others later, though).
Uwe Hermann [Sun, 27 May 2012 14:05:34 +0000 (16:05 +0200)]
srd: Wii Nunchuk: Complete rewrite, PD works now.
The Nintendo Wii Nunchuk protocol decoder, while it was in the repo for
a while, didn't really work yet (among other things, due to lack of
dumps for testing the code).
This is fixed now, the rewritten decoder works fine with most dump
files in the sigrok-dumps repo. A few minor issues remain to be
added/fixed, though.
If the (generated) ChangeLog file is marked for DISTCLEANFILES, it'll be
removed whenever "make distclean" is called (and is then gone forever if
you use the tarballs, for example).
Uwe Hermann [Tue, 22 May 2012 23:12:11 +0000 (01:12 +0200)]
srd: onewire: Fix incorrect format for annotation output.
Should be a list containing:
- Annotation format number (e.g. 0, or ANN_DEC, etc).
- A list of strings (the annotation). If more than one string is
supplied, the other ones should be short versions of the string.
Example: [ANN_DEC, ["Foobarbaz", "Foo", "F"]]
As per guidelines in HACKING, the protocol "commands"/items should be ALLCAPS,
thus change 'data' to 'DATA'. Also, fix MX25Lxx05D protocol decoder
accordingly, currently the only one we have which stacks on top of SPI.
Add a new 'CS-CHANGE' output protocol item, which is sent upon every
change of the CS# pin value (either 0->1, or vice versa). This is needed
by various higher-level PDs.
Pekka Nikander [Fri, 11 May 2012 16:23:21 +0000 (19:23 +0300)]
sr/srd/cli: Fix compiling with Homebrew.
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.
Uwe Hermann [Thu, 10 May 2012 07:34:13 +0000 (09:34 +0200)]
srd: Support for one or more optional probes.
In the protocol decoder you always get all required probes, then _all_
optional probes in the list of probes in the decode() call.
Example:
(r1, r2, r3, o1, o2, o3, o4) = pins
In this case r1-r3 are required probes, o1-o4 are optional probes.
However, the value of valid/used/specified probes will be 0 or 1,
whereas the value of probes that were not specified/assigned by the user
will be (at the moment) 42.
The PD can check for a valid probe like this:
if p in (0, 1):
...
Or check for an invalid probe:
if (p > 1):
...
The value of 42 could change to be -1 or None later.