Kongou Hikari [Thu, 5 Dec 2019 10:37:05 +0000 (18:37 +0800)]
cjtag: Add cJTAG OSCAN1 decoder.
[Note: This is a commit from Kongou Hikari ("diodep" on GitHub) that was
"rebased" by Uwe Hermann on top of the current libsigrokdecode mainline JTAG
decoder. There are various reasons for this, including avoiding non-mainline
or outdated decoder changes, as well as making it easily visible what the
changes vs. the current JTAG decoder are, in case we later need to apply some
changes to both decoders or in case both decoders might be merged later on.
Minor cosmetic and naming changes were also squashed in (no functional
changes, though).]
Uwe Hermann [Sun, 5 Jan 2020 14:49:18 +0000 (15:49 +0100)]
spiflash: Don't use ambiguous annotation class names.
This is not technically a bug since (at least some) datasheets refer
to this command as "Chip erase", it just happens to have two different
command codes (0x60 and 0xc7).
In order to not confuse users with two annotation classes with the
same name, we'll call the second one "Chip erase 2" to match the
"CE2" short name.
Gerhard Sittig [Wed, 27 Nov 2019 20:54:11 +0000 (21:54 +0100)]
dmx512: stack DMX512 on top of UART and improve usability
It was unfortunate that the previous DMX512 decoder implementation
re-invented UART decoder features and introduced new issues in the
process. Automatic polarity detection is just impossible when the full
set of valid DMX timings is to get supported. Sample numbers suffered
from floating point rounding errors.
Introduce a stacked decoder on top of UART which exclusively deals with
DMX512 details, and transparently benefits from all available UART
features (adjustable polarity, robust and correct sampling, data byte
accumulation, BREAK detection while silencing false STOP violations). On
one hand this requires users to specify the bitrate (250kbps), on the
other hand it results in reliable operation for all captures that have
become available so far.
Provide Python output for stacked decoders which can process protocol
extensions like RDM. Prepare the DMX512 decoder itself to handle simple
cases of protocol extensions (start codes other than 0). Add support for
additional constraint checks, emit warnings when user specified limits
are violated: short BREAK, long MARK, long RESET to RESET and short
BREAK to BREAK intervals. This shall speedup the identification of bus
health issues (data loss or corruption) or improper controller timing.
Also hide all-zero values by default, to make used channels visually
stand out, and help users focus their attention. For special cases (like
16bit data, or zero being a valid set-point for the channels) users can
enforce the display of all values. Provide an option to present byte
values to users in the most appropriate format for the use case.
Gerhard Sittig [Fri, 3 Jan 2020 21:59:47 +0000 (22:59 +0100)]
dmx512: remove previous implementation before replacing it
The existing DMX512 decoder implementation duplicates UART specific
knowledge, and implements some of the redundant logic in ways which fail
to interpret correct input data. See bug #1442 for details.
This commit removes the previous decoder implementation before adding a
more recent version, to gain a more readable history across that decoder
replacement.
Gerhard Sittig [Sat, 21 Dec 2019 16:02:50 +0000 (17:02 +0100)]
ps2: end data byte at rising clock edge of the stop bit
Data byte transmission is complete when the STOP bit was communicated.
End the STOP bit at the rising CLOCK edge of the 11th bit time, do not
rely on the host's clock inhibit after data transmission. This avoids
the unexpected expansion of a STOP bit well into the next data byte.
This fixes bug #1460, where absence of host activity after the first
data byte loses synchronization to the input stream.
Rephrase pin level sampling while we are here. Reflect that the clock
line is used for .wait() conditions, but its level is not evaluated.
Only data line levels get processed.
Comment on the implementation's assumption of specific input data (the
device as transmitter, host transmit may not be supported, or can result
in unexpected output). Which may be acceptable yet maintainers need to
remain aware.
Uwe Hermann [Mon, 30 Dec 2019 11:20:45 +0000 (12:20 +0100)]
uart: Use human-readable names for annotation classes.
Using human-readable names for annotation classes (instead of numeric
indices) improves readability and maintainability of the decoder, and can
also prevent bugs due to incorrect indices.
Gerhard Sittig [Tue, 17 Dec 2019 10:48:23 +0000 (11:48 +0100)]
uart: sample position nits, fix typo, float calculation awareness
This commit amends bd50ceb314e4. Fix a typo in a comment. Rephrase the
bit width percentage calculation such that readers remain aware of the
necessity for floating point math in sample position calculations. This
commit does not change behaviour, Python 3 always yields float results
for divisions. It's about raising awareness.
Gerhard Sittig [Wed, 4 Dec 2019 20:21:03 +0000 (21:21 +0100)]
uart: allow arbitrary sample positions for UART bit values (1-99%)
The previous implementation of the UART decoder used to sample bit values
strictly at the center position within a bit time. This commit introduces
support to sample bit values at arbitrary positions in the range of 1-99%
of the bit time. This allows to work around glitches in existing captures
as well as using the decoder for UART like protocols which don't sample
bit values at the center position (like EIB aka KNX).
This implementation is incomplete (on purpose). Although this version
improves the ability to extract data from captures, it also introduces
inaccuracies in the annotation positions for non-default values of the
sample point position. Addressing this issue is left for later, assuming
that it'll be a byproduct of another commit series that is being worked
on (general annotation position adjustment and stop bits support).
Gerhard Sittig [Thu, 12 Dec 2019 09:39:57 +0000 (10:39 +0100)]
signature: increase compatibility across Python versions
Underscores in number literals are a recent Python feature which only
was introduced in version 3.6. The sigrok project claims compatibility
with previous Python versions, but the signature decoder fails to load
with this error:
$ pulseview
srd: SyntaxError: Failed to load decoder signature: import by name failed: invalid syntax (pd.py, line 138)
srd: Traceback (most recent call last):
File "/home/user/share/libsigrokdecode/decoders/signature/__init__.py", line 25, in <module>
from .pd import Decoder
File "/home/user/share/libsigrokdecode/decoders/signature/pd.py", line 138
incoming = (bin(shiftreg & 0b0000_0010_1001_0001).count('1') + data) & 1
^
SyntaxError: invalid syntax
Use the more compact hex presentation for a magic binary pattern. This
obsoletes the necessity to separate groups of bits for readability.
Dave Craig [Wed, 2 Jan 2019 13:36:11 +0000 (13:36 +0000)]
Add HDCP traffic decoder to stack on i2c
This decoder annotates i2c traffic to indicate the type of HDCP
message contained. It includes HDCP2.2 and HDCP1.4. Useful for
analysing HDCP negotiation failures.
Gerhard Sittig [Sat, 7 Dec 2019 07:58:34 +0000 (08:58 +0100)]
ieee488: flush upper layer payload data when IFC asserts
Also flush previously accumulated payload data when the IFC signal
asserts (interface clear, a controller requests ownership of the bus).
This is in line with EOI (end of message) and ATN (start of a command,
including change of "connected" peers or direction of communication).
Gerhard Sittig [Sat, 7 Dec 2019 07:51:16 +0000 (08:51 +0100)]
ieee488: introduce 'delim' option for improved text output
When a capture contains output from a talking device, but neither
contains EOI (end of transmission) nor ATN (new commands, including
changes in the set of communicating peers or communication direction),
then lower layer data bytes would be shown but accumulated runs of upper
layer payload data would not. The hp53131a-ton.sr capture demonstrates
this behaviour.
Add transparent support for the typical case of communicating SCPI over
GPIB. Do emit upper layer payload data annotations when termination
sequences for text lines were seen. Allow users to disable this feature
when it's not appropriate for binary content.
It's an internal implementation detail that accumulated data gets flushed.
Communicate the user visible option as "payload data separation", which
should most appropriately reflect the resulting behaviour. The specific
implementation of this feature can also support different kinds of payload
chunk separation.
Gerhard Sittig [Thu, 3 Oct 2019 02:38:01 +0000 (04:38 +0200)]
ieee488: introduce unified IEEE-488 decoder (supports GPIB and IEC)
Introduce an 'ieee488' protocol decoder which handles both the 16 lines
parallel GPIB variant as well as the serial IEC bus variant. Which kind
of supersedes the 'gpib' and 'iec' decoders.
This implementation increases maintainability because only the extraction
of raw bytes from the parallel or serial bus is separate, and all GPIB
related command/address/data interpretation is shared. This decoder extends
the feature set of the previous versions: Visual annotations are more fine
grained (more classes, additional rows, various text lengths to maintain
usability during zoom). There is binary output for communicated data,
as well as Python output for stacked decoders. Consecutive runs of
talker data gets accumulated, and is made available in binary form as well
as text (with escapes for non-printables). The terse single-letter format
(character codes '0' to 'O' for addresses) is kept for compatibility for
those users who are accustomed to it. The implemented logic also copes
with captures of low samplerate, where edges happen to fall onto the same
sample number which at higher samplerates shall be perceived as distant
and should get processed in their respective order of appearance.
This implementation tracks the most recent configuration of "peers" (the
set of talkers and listeners). A future implementation might support the
isolation of a single conversation out of a busy chat on the bus.
Some optional support for Commodore peripherals is included (currently
limited to disk channels), while it's recommended to move this logic to
a stacked decoder if it grows more complex.
Gerhard Sittig [Fri, 29 Nov 2019 20:15:48 +0000 (21:15 +0100)]
uart: support 'ignore' parity type, remove unsupported 'check_parity' option
The previous UART decoder implementation announced a 'check_parity'
option which took no effect (support code was missing). Remove it. Add
another 'ignore' parity choice instead, which consumes the parity bit's
position yet always passes the check.
Gerhard Sittig [Thu, 10 Oct 2019 07:01:01 +0000 (09:01 +0200)]
can: more robust sample point position for low sample rates
Do more of the calculation with floating point, only trim precision and
enforce integers at the end of the determination of the next sample
point. This shall increase robustness at low capture sample rates.
Gerhard Sittig [Sat, 20 Oct 2018 18:48:46 +0000 (20:48 +0200)]
uart: communicate periods of idle frames to stacked decoders
Detect periods of a frame's length with idle level, and communicate
these time spans to stacked decoders by means of PYTHON output. Do *not*
display these idle frames in regular annotations, for backwards compat.
Gerhard Sittig [Sun, 24 Nov 2019 18:45:01 +0000 (19:45 +0100)]
gpib: drop obscure "total number of samples" option
The gpib decoder tried to "flush" input data at a user specified sample
number when the input data lacked the respective edge which triggers the
processing during regular operation.
This is rather obscure a feature, not seen in any other decoder, perhaps
a workaround for bug #292, rather unaccessible to users (units of sample
numbers not times nor automatic detection of the EOF condition), highly
confusing according to user reports, and not covered by existing tests.
The mere presence of this option caused severe issues in application
code (see bug #1444). While there is no apparent fix that won't affect
other decoders. So let's drop this questionable feature. Valid and
complete captures should contain all relevent edges and thus decode
properly.
A recent commit tightened the check for acceptable 'skip' sample counts.
This broke the onewire_link and usb_signalling decoders' test sequences,
which no longer pass with a minimum count of one. Relax the condition
and accept a count of zero. This breaks gpib again for low total sample
count option values, but this needs to get addressed differently.
Gerhard Sittig [Sun, 24 Nov 2019 08:52:42 +0000 (09:52 +0100)]
decoder: internal 'always false' term, handle invalid skip and channel
Introduce an "always false" type for .wait() terms. Map invalid counts
of skip conditions (zero or negative numbers) as well as invalid channel
references for level/edge conditions to this type which never matches.
Keep this "always false" term type an internal detail of the common
support code.
This is most robust and least intrusive at the same time, it keeps the
existing API, and simplifies the implementation of Python decoders for
rare edge cases (optional input signals or optional features, handling
of initial samples at the very start of a capture).
This commit passes sample counts internally in a signed data type. This
is essential for proper operation, and the loss of one bit out of 64
shall not be considered a severe limitation.
This is a protocol decoder for the 'ASCII' protocol used by
Amulet Technologies LCDs.
Currently some commands are not implemented yet. I also lack capture data
from a display that will use replies other than ACK and NACK.
Reads are untested as I have no suitable captures.
The PD copes with bus errors (there is an actual bug in the device I'm
reverse engineering) and most of the commands are implemented.
The unimplemented commands should generally consume the correct
number of bytes from the bus, the exception to this are the drawing
commands, because there are actually at least two revisions of them
with different payloads, that are really hard to detect in greedy
algorithm.
Uwe Hermann [Sat, 23 Nov 2019 16:45:23 +0000 (17:45 +0100)]
Fix three -fsanitize=undefined issues.
instance.c:62:2: runtime error: null pointer passed as argument 1, which is declared to never be null
instance.c:858:45: runtime error: shift exponent -1 is negative
instance.c:836:45: runtime error: shift exponent -1 is negative
Uwe Hermann [Sat, 23 Nov 2019 15:42:44 +0000 (16:42 +0100)]
Avoid using Py_IncRef/Py_DecRef for consistency.
We currently use a mix of Py_IncRef/Py_DecRef and Py_XINCREF/Py_XDECREF
or Py_INCREF/Py_DECREF in the code-base. Only use the latter variants
for the time being (for consistency).