| Age | Commit message (Collapse) | Author |
|---|
|
Sample and process multiple STOP bits as specified, add 2.0 to the list
of supported configurations. This implementation works as expected with
integer numbers of STOP bits (0, 1, 2). For half-bits the sample point
as well as the annotation position will be incorrect (as a result of an
internal implementation detail of the existing decoder which is not easy
to address).
This commit reduces the diff size, and remains backwards bug-compatible.
Fixing the bit boundaries in annotations including support for half-bits
is more involved, and remains for a later commit.
|
|
Use common code to advance internal state during UART frame inspection.
This reduces redundancy, and improves robustness. Data bits collectors
need not worry about the optional presence of subsequent fields (parity,
stop bits, both can be absent).
Improve the separation of implementation details of the lower layer UART
frame decoding from upper layer protocol handling. Concentrate the post
processing of UART frames, BREAK and IDLE conditions in the source, and
keep the ss/es determination at the caller which detected the condition
by arbitrary means.
This unbreaks the decoder's operation when 0 stop bits are configured.
The implementation still assumes that the line goes idle between frames
even when zero stop bits are configured. Strictly speaking this decoder
now copes with traffic that uses "less than half a stop bit".
|
|
|
|
|
|
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).
|
|
This is managed by the backend and should be read-only for PDs.
|
|
|
|
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).
|
|
|
|
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.
|
|
Similar to the recently added [rx|tx]_packet_delimiter options, these
emit summary annotations ("packets") when a certain number of data values
have been decoded.
This is a convenience feature which can be useful when a user wants to
view data which doesn't have a specified delimiter value (as last data
value in the "packet"), but rather fixed-length "packets".
This is just an (intentionally very simple) helper/convenience improvement
and is NOT meant to replace "proper" stacked decoders for UART-based protocols.
|
|
This is a convenience feature that emits summary annotations ("packets")
that comprise all data values that were decoded until a specified delimiter
value is seen (as last data value of the "packet").
Example use-cases include ASCII data where it can be convenient to
"packetize" whenever a 10/0x0A value (newline) is seen, or some
protocols which have a fixed "marker" value (e.g. 0x55) as last
value in the "packet".
The annotations are affected by the selected 'format' option, i.e. the
user can get summaries in ASCII or hex or other formats.
This is just an (intentionally very simple) helper/convenience improvement
and is NOT meant to replace "proper" stacked decoders for UART-based protocols.
|
|
|
|
|
|
The "Frame error?" TODO comment on Python annotations has become
obsolete. Individual bit errors within the frame immediately get
communicated as they are detected (START, parity, STOP). The overall
frame's validity has become available with the FRAME annotation.
|
|
Internally keep track of the UART frame's validity. Emit a FRAME Python
annotation for aborted as well as for completed frames. This obsoletes a
TODO comment in the STOP bit code path.
This annotation also spans the complete frame's length, including start
and parity and stop bits, which the DATA annotation doesn't cover.
Stacked decoders can individually decide whether to strictly reference
the mere data bits section or the complete UART frame which happened to
communicate the data value.
|
|
|
|
There are the "traffic inspecting" wait() conditions, which check an
edge to find the start of START, then wait for sample points to grab the
bit values. Bit times are sampled in their respective center, potential
glitches around sample points get ignored.
Add another independent set of wait() conditions which check _all_ edges
regardless of any data communication. This results in the most reliable
and maintainable detection of break conditions, regardless of how they
align to data frames. Break is defined as a period of low input signal
which spans at least one frame's length. Run the edge inspection after
data inspection, which results in the most appropriate annotation output
like leading data bits (of incomplete frames), frame errors (violated
STOP bit expectations), then break conditions. This approach is most
robust in the presence of incomplete input streams.
|
|
Use the already available .databits[] information which holds sample data
and bit time edge positions, and the common bitpack() routine. This shall
increase readability of the bits to value conversion.
[ best viewed with more context, like 'git diff -U5' ]
|
|
Move initialization code of protocol decoders from the constructor to a
new reset() helper method. The libsigrokdecode backend could run this
method several times to clear the decoder's internal state, before new
data from another acquisition gets fed to decode() calls.
|
|
|
|
Slightly rearrange some of the methods which are involved in UART frame
inspection. Use a consistent sequence of steps: Grab the signal's
current value, accumulate and process the information, emit respective
annotations, and advance to the next stage in the UART frame inspection.
|
|
After the decode() method got adjusted to call wait() with custom made
conditions and to check .matched[] before inspecting samples, the check
whether a bit time's sample point was reached has become obsolete.
|
|
Since either of the UART signals (RX, TX) is optional, and in the
absence of Decoder.wait() conditions that "will never match", we cannot
construct a constant layout. Instead we need to explicitly keep track of
which item in the list of wait conditions corresponds to which signal.
Once the index in the list of wait conditions is known, inspection of
samples can depend on the Decoder.matched[] attribute. Before this
change, redundant reached_bit() checks kept us from processing samples
that should not have been inspected. Tests pass before and after this
very commit.
|
|
Factor out the logic which inspects samples that were provided by the
PD version 3 query API, and dispatches their processing depending on
the progress of UART frame inspection. "Unroll" a loop over the RX and
TX signals.
This commit replaces some complicated variable assignments by easier to
verify invocations.
|
|
Adjust the UART protocol decoder, to make use of the query based API.
Have edges detected and unrelated samples skipped by common code.
This implementation keeps some redundancy in place (like checking for
having reached specific sample numbers, while the backend managed that
for us). This approach reduces the diff and shall simplify review.
Only some common checks in decode() were moved to the start of the
routine, outside of the sample inspection loop.
|
|
Rephrase the bit slot index calculation for UART frames such that it
becomes more apparent whether a start bit is involved or whether an
array index needs adjustment due to Python range semantics.
This shall improve readability, and reduce the probability of off-by-one
errors during maintenance.
|
|
When the UART frame does not contain a parity bit, then immediately
advance to reception of stop bits after all data bits were received.
This eliminates the necessity to run the parity check routine when
parity does not apply in the first place. Without this change, some
"dummy" sample needs to get inspected for correct operation of the
state machine.
|
|
|
|
Remove the FSF postal address as it might change (it did in the past).
Reference the gnu.org website instead which is more stable.
|
|
This is in almost all cases what the user will want, only rarely ASCII
(the old default) will be the more natural fit.
|
|
For 5..8 data bits the binary output will be 1 byte, for 9 data bits
it will be 2 bytes (big-endian).
This fixes bug #708.
|
|
When the start bit is not low at its sample point, then stop trying
to interpret the remaining frame -- it's already known to be invalid,
anyway.
Wait for the next start bit instead, assuming that either the falling
edge which started the inspection of the UART frame and its start bit
was a spurious glitch or that the captured signal does not communicate
at the decoder's configured bitrate.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
|
|
Factor out the code which generates a textual representation for the
numeric values that were communicated via UART bit patterns. Make the
width of the output text depend on the number of bits in the UART frame
(five to nine) instead of assuming bytes of exactly eight bits.
Fix other minor issues while we are here: Nine bits result in a number
range of 0 to 511 (not 512). ASCII codes 30 and 31 are non-printables.
The previous implementation skipped a significant leading digit in the
octal representation.
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
|
|
Given the generic nature of UART communication and the supported range
for the data width, "byte" may be a misleading name for the numeric
value that gets communicated in five to nine data bits. Rename the
"databyte" variable to "datavalue".
Signed-off-by: Gerhard Sittig <gerhard.sittig@gmx.net>
|
|
The UART bit information was not transmitted correctly to stacked PDs
if there was an overlap between RX and TX bytes in the data.
|
|
The previous **kwargs some PDs had is not actually ever used, so drop it.
|
|
Re-enable the fast path for identical samples but only when both
pins are waiting for the start bit. For sparse data sets (I tested
UT61E capture log) the optimization results in a >4x decode
improvement.
|
|
|
|
This is more consistent with annotation syntax and looks slightly
better in most cases.
|
|
1. Show Frame Error on the Start bit
2. Don't overwrite framing errors with (valid) start/stop bit info
|
|
At 3 samples per bit, the uart decoder took the value at the last sample
instead of the middle one. Improve calculations so that sampling is more
accurate at odd number of samples per bit.
|
|
|
|
This will allow for much simpler code in stacked PDs.
Adapt stacked PDs to new API.
|
