sae_j1850_vpw: rewrite decoder to improve usability and maintenance The previous implementation of the SAE J1850 (VPW) decoder dumped bytes on one row and added another row with textual labels what those upper row bytes would mean. That allowed manual inspection at a rather low level of abstraction, but is not idiomatic and reduces usability of the decoder. Rewrite the decoder to become more idiomatic, and to prepare future inspection of more upper layers. Concentrate all timestamp gathering in .decode(), use PD API v3 for the IFS timeout as well, run handlers for the lowest level symbols. Pass accumulated protocol bytes to a fields handler, flush accumulated details when EOF is seen. Prepare validity checks (checksum verification), and prepare to handle data bytes when all header fields were seen and validity was checked. Emit annotations in proper classes to improve usability, start emitting warnings. Force re-synchronization when input stream conditions are not handled.
rgb_led_spi: adjust decoder implementation's Python style Eliminate unneeded instance variables. Start from None when values are unknown. Only access data after checking its availability. Invalidate previously accumulated details after processing. Prefer .format() over string modulo. Use list .clear() where applicable. Use symbolic names for annotation classes.
rgb_led_ws281x: default to RGB[W] annotation text order The earlier default was "RGB" (exactly three components), and users had to manually pick "RGBW" when white was involved. Change the default to the automatic "RGB[W]" instead which transparently presents white when applicable, and doesn't fail when white is not involved.
rgb_led_ws281x: emit annotations for individual colour components The previous implementation presented bits and per-LED RGB-values (in a from similar to HTML colours). This commit introduces annotations for individual colour components (R/G/B/W) between these two levels of abstraction.
rgb_led_ws281x: add developer comments, link to chip datasheets Add developer comments at the top of the decoder source. Reference datasheets, discuss vendor's numbers and what's used in the field. Discuss variants (sets of involved colour components, alternative timings, reset detection).
rgb_led_ws281x: support more colour component orders (wire, and text) The 'type' option was not good enough. Replace it by 'wireorder' (order of colour components on the wire, depends on the RGB LED chip type), and 'textorder' (presentation to users in annotations). Support many more layouts of colour components on the wire. Cover all permutations of R, G, and B. Support a few RGB plus W layouts that are known to be in use. Adding more is just a matter of adding more choices in the option, the implementation transparently follows. Support a few text orders: Reflect the very order of bits on the wire. Automatic support for RGB with optional White, or fixed RGB or RGB-W variants (all are users' choices, default remains "RGB" for backwards compatibility). Support arbitrary combinations of wire order and text order in emitted annotations. Keep support for the weird RGWB text format, which the previous decoder implementation used for "all" RGBW types, and which is referenced by existing test cases. It is uncertain which chip type is supposed to generate this specific RGBW traffic. It is as uncertain why this text order was chosen, which neither is the human readable RGBW format nor matches the wire order. The previous implementation was introduced in commit 47ff9910f7e1, but neither commented nor referenced literature or external sources nor did the commit message contain any clues. This current implementation needs more tests and reviews, but lends itself better to maintenance, fixes and enhancements.
rgb_led_ws281x: rework the .decode() main loop, improve robustness Concentrate timestamp gathering in the .decode() method, eliminate instance members by using variables that are local to the method. Finally use appropriate PD API v3 invocations. Use edge conditions plus a counted 'skip' to detect the RESET pulse. Use a positive "check the reset condition" logic, simplify the conditions which support the reset pulse tracking, and which flush previously accumulated data when "the bit time doesn't end" (the next edge is missing). Improve robustness in those cases where captures use low oversampling and similar length high and low pulses. The fixed (rather arbitrary?) 625us threshold resulted in several false last-bit values after the API v3 conversion. Heavily comment on this edge/pulse detection and timestamps logic, since it's non-trivial and non-obvious. Keep all behaviour backwards compatible before extending the feature set in future commits.
rgb_led_ws281x: refactor bit/bits handling, use more common code Pass all .decode() routine's bit handling through a common bit handler. Accumulate the bit values as well as their ss/es timestamps. Reduce code duplication in the bits handler. Use common support code to get the 24/32 bit wide integer from the list of bits. Prepare to handle streams of different per-pixel length or layout. This commit remains backwards compatible, and keeps all warts of the previous implementation including inconsistent annotation order. Just eliminates unnecessary instance members and hidden coupling, to keep timestamp handling in the .decode() method.
rgb_led_ws281x: rephrase .put() calls for readability Separate the construction of the list of texts for different zoom levels from the emission of annotations. Use a .putg() helpers to match other decoder implementations. Prefer .format() calls over "modulo" operations on strings.
i2c: rephrase state machine, eliminate text matching Rephrase the conditions which drive the I2C decoder's progress. Remove self.state and its space separated string literals which were tedious to search for, and which "lent themselves" to magic string matching. Use other existing conditions instead, which also reduces redundancy. Defer the "forgetting data bits" until after ACK was seen. Comment on the motivation to keep the "protocol violating" implementation, which misses error conditions that happen on the wire, but happens to support heavily undersampled captures to an astonishing degree. Also addresses minor style nits: Prefer to think of "dominant ACK" and "recessive NAK". Rephrase a byte shift for the first address byte. Emit the first warning annotation for the row which was declared before but was not used so far.
i2c: concentrate sample number and value getting in main loop It's unfortunate how the symbol / bit value handlers of the I2C decoder keep redundantly accessing the .samplenum property. Ideally they should just get an ss, es, value tuple, while the determination of these params should be kept in the .decode() main loop. Prepare the internal implementation to that approach, but enforce an absolutely backwards compatible behaviour for now. This was verified by the test suite. The data bit handler still keeps updating previous bits' end positions when another bit is seen. Which assumes back to back bits which strictly speaking does not match the protocol's definition. The unfortunate application of the second last bit time's width to the last bit time and the ACK slot is kept as well. And the code path needed to be kept within the bit handler, because the second last bit's width only becomes available when the last bit _was_ handled. Which means that the main loop cannot provide a useful es value which matches the previous implementation's behaviour.
i2c: unobfuscate ss/es passing for put, document BITS order Eliminate how the I2C decoder's put methods take data as arguments and hiddenly take ss/es from instance variables. This improves readability during review. Rename .putx() to .putg() to match other decoders (emits graphical annotations, in contrast to Python and binary). Document the surprising BITS pdata order, stacked decoders get LSB first sequences. To keep awareness during maintenance. Keep an explicit copy of the LSB bits to simplify the implementation of the data byte handler (sample numbers remain available at indices in their reception order).