uart: don't re-calculate in-frame bit position, just count the bits The .get_wait_cond() routine kept re-calculating the current bit index in the currently inspected UART frame. Just count the bits instead as they are seen/taken. This eliminates redundant complex logic which had hard to track down issues in past revisions. Increases robustness, and improves maintainability.
uart: handle two stop bits configuration 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.
uart: handle zero stop bits configuration 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".
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.
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).
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.
uart: Add [rx|tx]_packet_len options. 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.
uart: Add [rx|tx]_packet_delimiter options. 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.