| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
Previously there were two different annotation classes with 100% overlap.
|
|
This was causing incorrect annotation class indices to be used.
|
|
|
|
|
|
|
|
This fixes bug #1474.
|
|
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.
|
|
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.
|
|
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).
|
|
|
|
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.
|
|
|
|
|
|
All PDs where "trivial" self.wait() conversion was used now have this
specific comment, so it's easy to grep for.
|
|
This is managed by the backend and should be read-only for PDs.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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).
|
|
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.
|
|
|
|
This can be used by frontends for decoder search features.
|
|
|
|
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.
|
|
|
|
|
|
|
|
This avoids floating point number option values, which makes things
a bit easier/clearer on the command-line and also matches what other
decoders do.
Also, use numbers instead of strings for the option values.
|
|
|
|
|
|
|
|
This makes the decoder a lot nicer to use from the command-line.
* num_data_bits -> data_bits
* parity_type -> parity
* num_stop_bits -> stop_bits
* rx_packet_delimiter -> rx_packet_delim
* tx_packet_delimiter -> tx_packet_delim
|
|
Rephrase the test for the availability of at least one of several
optional input signals, and reword the corresponding error message.
|
|
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.
|
|
|
|
Generally show "bits" and other smaller annotations in rows that come
before "larger" annotations (in later rows).
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
Without this, e.g. the recently added 'IDLE' ptype of the UART decoder
would cause issues.
|
