| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The functionality of the preliminary 'uart_dump' PD is now available
in the proper 'uart' PD, via the OUTPUT_BINARY mechanism that frontends
can use to dump decoded data (in various formats) to a file, or pipe it
into other applications, and so on.
Old sigrok-cli example usage:
$ sigrok-cli -i foo.sr -P uart:rx=0:tx=1,uart_dump:filename=bootlog.txt
New sigrok-cli example usage:
$ sigrok-cli -i foo.sr -P uart:rx=0:tx=1 -B uart=rxtx > bootlog.txt
New sigrok-cli example usage (piping into other applications):
$ sigrok-cli -i foo.sr -P uart:rx=0:tx=1 -B uart=rxtx | grep "whatever"
|
|
We use the [XX] notation for non-printable characters, which is what
various other logic analyzer software packages do too, e.g. the
CWAV USBee Suite.
This fixes bug #201.
|
|
This automatically figures out the files to install for each protocol
decoder, without involving autotools.
All python files (filenames ending in .py) are always installed. If a
protocol decoder requires installation of a non-python file, a small
file called 'config' can be created in that protocol decoder's
directory, with the following content:
# comments are ok
extra-install vendorlist.txt commands.txt
|
|
|
|
|
|
This better reflects what it is: a python object generated and
processed by python code.
|
|
|
|
There is one annotation type for the RX side of the communication/data
output now, and another one for the TX side.
This allows GUIs to show them in two different traces, and/or show them in
the same trace but with different colors.
This also has the additional benefit that it is clear which databyte
belongs to which direction. Previously the annotations had to look like
"RX: 5F" or "TX: 11001011", but the "RX: " and "TX: " prefixes are now
no longer required, making the GUI traces (and CLI output too) much more
readable.
|
|
Until now you could get e.g. "d" or "df" as hex output from the UART PD.
This will now be a common-length "0D" and "DF". When all data byte
annotations are of the same lengths the readability in GUI traces is a lot
better. Also, hardcode hex characters to be upper-case (for now).
The same applies to oct ("021" instead of "21") and bin output
("00001001" instead of "1001").
|
|
There are now extra annotation types for data, start/stop/parity bits and
for warnings (e.g. "invalid parity" or "frame error" or such).
This allows users to select which of the annotation types they want to
see (they can select one/multiple/all annotations as needed), and also
allows them to use different visual representation for the different
annotation types in GUIs (e.g. different colors for the blobs, different
fonts, rectangle/round/elliptic blobs, and so on; how the annotation
blobs are displayed is entirely up to the GUI and its configuration by
the user).
|
|
This is information that a user (when viewing PD info in a GUI/CLI)
should not see (and doesn't care to see), it is meant for developers only.
Thus, make it a comment in pd.py instead.
|
|
Move the full details of the protocol to the wiki, the docs in the PD
itself should only be a short description and/or a collection of notes
that could be useful for a user in a GUI (or CLI) to decide which
PD to select, which options to set how, what PDs to stack where, and so on.
The full protocol description (including photos, examples, ...) is here:
http://sigrok.org/wiki/Protocol_decoder:Uart
|
|
Until now we (ab)used annotation types for outputting the same data
(numbers) in different formats (hex, ascii, binary, and so on).
Turn this into a proper PD option, since annotation types should rather be
used for different _types_ of annotations (e.g. "CRC", "Stop bit",
"Preamble", "Sequence counter", "Warnings", and similar things), not
different _formats_ for the same annotation type.
Old sigrok-cli invocation for hex output:
sigrok-cli ... -P uart:rx=0:tx=1 -A uart=hex
New:
sigrok-cli ... -P uart:rx=0:tx=1:format=hex
In GUIs there is now a new "Data format" option where the user can
select the output format for UART data (default is 'ascii').
|
|
The short(est) annotations for "Stop bit" and "Parity bit" have both
been "P" until now, which is confusing for users (on certain zoom levels
in GUIs). Use "T" for stop bits now instead.
|
|
Previously the output was 0x41 or 0o101 or 0b1000001, now it is 41 or
101 or 1000001. We drop these prefixes, since they decrease the readability
of the PD output (especially when displayed in GUIs) and are not needed
anyway since the user knowingly selected the number format before running
the respective PD.
|
|
Assume that the initial pin state is 1/high for the RX and TX lines.
This fixes the decode when an LA triggers on e.g. TX=low (the first
sample would be low in that case, so the falling edge for the start bit
would be missed by the decoder).
|
|
This now makes the UART decoder suitable for use in GUIs.
This fixes bug #148.
|
|
|
|
|
|
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.
|
|
Thanks Iztok Jeras <iztok.jeras@gmail.com> for the report.
|
|
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 <lars@metafoo.de> for bringing this to our
attention.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While this has a (small) performance penalty compared to using integers,
it has the advantage of not requiring the use of magic numbers which
need to be declared in both the UART decoder and all decoders which
stack on top of UART.
|
|
|
|
|
|
|
|
- List all API methods and metadata variables in all PDs to make things
easier and more consistent for new PD writers.
- Fix probe assignment in a few PDs.
- Raise exceptions upon invalid states of the PD state machines (bug).
|
|
|
|
|
|
|
