| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
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.
|
|
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).
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
|
|
Support of the now common RGBW type LED strips (uses 4 bytes instead of 3).
Added an option to select RGB or RGBW
|
|
|
|
|
|
Only add items to 'outputs' if the respective PD actually has
OUTPUT_PYTHON support implemented as of right now.
Various decoders might get OUTPUT_PYTHON support later, but the
'outputs' field should reflect the current status.
|
|
|
|
|
|
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.
|
|
Telling .wait() to "skip one sample" slightly obfuscates the intent of
getting the next samples while no condition applies. Explicitly pass no
condition arguments instead, to better reflect the purpose. Coincidently
these .wait() calls will execute in slightly less expensive code paths
in the common code.
|
|
|
|
This is currently just a cosmetic change, but will make the conversion
to the PDv3 API slightly easier and more readable.
|
|
Remove the FSF postal address as it might change (it did in the past).
Reference the gnu.org website instead which is more stable.
|
|
|
|
The previous **kwargs some PDs had is not actually ever used, so drop it.
|
|
This decoder handles the WS2812B protocol (and possibly WS2811).
Example dump already exists: led/ws281x/ws281x_4ch_5mhz.sr.
Signed-off-by: Vladimir Ermakov <vooon341@gmail.com>
|
