| Age | Commit message (Collapse) | Author |
|---|
|
Add support for register field content checkers, and emit warning
annotations when they yield non-empty results. Implement a checker for
the INT field of register R0. Reduce the allowed values' lower limit
from 32 (previous implementation) to 23 (ADF4350 datasheet, figure 24).
|
|
Move table columns, put the bit field position to the front before the
name to get a less fragile visual appearance. All fields have a position
and a name (of variable length), some of them have a "parser" (actually
a formatter for their content).
Address Python style while we are here: Prefer tuples over lists for
immutable data. Add trailing commas to reduce future diff sizes.
Add a TODO comment about optional content checkers. The current decoder
implementation lets invalid register data pass unnoticed.
[ see a word diff for the commit's essence ]
|
|
Try a different presentation of exising information in the register
fields' display text construction (extra parsers for known fields).
Attempt a source code format which hopefully better lends itself to
index range verification during review.
Make the number of available expansion texts stand out more visually,
so that readers can compare their count to the register field's width.
Address those register fields with four or more expansion values, keep
the simple single bit cases as they are. Add a comment for awareness.
|
|
Rephrase the old style '%' operator string formatting, prefer .format()
calls instead. It is assumed that routine call argument lists are more
readable than optional/conditional tuples are, and not running format
specifiers and literal text into each other helps readability as well,
as do the .format() routine's optionally named references to parameters.
Avoid text formatting which involves concatenation, always work from one
single format instruction instead.
|
|
Move the inspection of a completed 32bit word into the .decode_word()
routine. This simplifies checks for fatal constraints, as well as
optional inspection of deeper detail levels when extra parsers are
available.
Rename variables in the code path which accumulate bits. Add comments
to helper routines and to essential steps in complex interpretation
code paths. Eliminate the unused return value of the .decode_field()
method. Results in a lean and readable .decode() body.
|
|
Separate data processing from text formatting in the code paths which
emit annotations. Introduce a local .putg() helper. This unobfuscates
the decoder's operation, and also happens to shorten text lines. Raises
awareness for zoom levels and alternative text during maintenance.
This commit incompatibly rephrases the "Wrong number of bits" message.
|
|
Use .extend() and .clear() for the Python list during accumulation of a
32bit word's bits sequence. This shall improve readability. Performance
is less of an issue since this decoder's data amount remains small
(32bit entities per SPI transfer).
Comment on the unexpected(?) SPI decoder's BITS ordering when passing
details up to stacked decoders. Raise and keep awareness for this
non-obvious implementation detail during decoder maintenance.
This implementation accumulates bits in the MSB order as they are sent
in SPI frames. Yet keeps the LSB bit order when a completely accumulated
32bit word gets inspected, to reduce the diff size. Bit field extraction
and annotation emission code paths assume a specific timestamp ordering.
The separation of transport and inspection also simplifies maintenance,
should a future SPI decoder provide BITS in their received order.
|
|
Use common support code to convert bit fields to integer numbers. Also
unobfuscate the decode_bits() method and its returned values' layout.
Improves readability and factors out common expressions.
|
|
The previous implementation of the ADF435x decoder assumed knowledge of
internal details which are the SPI transport layer's responsibility. And
encoded an inappropriate chip select polarity in the process (falling
CS edge). The datasheet specifies that previously clocked in data bits
get latched on rising LE edges.
Not all setups were affected, that's why the issue went unnoticed before.
Use the lower layer's TRANSFER annotation to process the completion of
an ADF435x register access, after BITS annotations made the location of
individual bits available. The LE (CS) signal's polarity remains a detail
of the SPI decoding layer, and must be configured there. The SPI decoder's
default matches the ADF435x chip's expectation.
This fixes bug #1814.
Reported-by: Martin Homuth-Rosemann <homuth-rosemann@gmx.net>
|
|
Check the bit count of SPI transfers. Only start inspecting ADF435x
register content when the accumulation of the expected 32bit word has
completed. Emit a warning annotation for unexpected transfer sizes.
|
|
Avoid generic variable names. Only unpack parameters which are provided
by the lower layer decoder after the stacked decoder checked their type
and is aware of their meaning.
|
|
The "parallel" decoder buffers the currently seen data pattern, and
defers annotation emission until the end position is known. Which is
why the last data pattern would not show up in the decoder's output.
See bug #292 and its duplicates for examples and concerns.
Catch the EOFError exception, and flush previously accumulated data.
It is yet to get determined whether a warning annotation is due. Most
probably not for "parallel" which merely visualizes data line states.
But other decoders which have the concept of frames shall NOT follow
this "parallel" decoder's naive approach, and claim that a frame had
completed although its end condition was never seen. Add a developer
TODO comment to raise awareness.
|
|
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.
|
|
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 is the SBUS remote control by Futaba, the 25 bytes on top of UART.
Not the computer peripheral bus. Hence the suffix in the decoder name.
The implementation was tested with synthetic data. Example captures with
real world data have yet to become available. This implementation shows
the message framing, the proportional and digital channels' values, and
the flags. Several warnings for short and long and invalid messages are
implemented, as are user adjustable channel value range limits.
The boilerplate may need adjustment. All naming was made up by me based
on what information was available (vendor doc was missing).
|
|
Rephrase how the external IRMP library gets loaded, to provide better
diagnostics to users. All decoder instances are equal after the recent
introduction of locking support.
Move the "reset state" call for the IRMP decoder core to the .decode()
method's main loop, where the context manager holds the instance lock.
This allows "parallel" execution of multiple IRMP decoders in the same
sigrok application, assuming that the context manager scope will be
left at some point in time.
This fixes bug #1581 when applications communicate EOF to decoders.
Move some Python object members to local variables. They exclusively
are used within the .decode() method.
Update the copyright for the non-trivial changes.
|
|
Extend the ctypes wrapper for the IRMP decoder core. Add routines for
the instance state creation and lock management. Implement metamethods
for Python context managers which lock the instance to protect the C
library's internal state from changing unexpectedly. Add my copyright
for the non-trivial changes.
This commit eliminates the limitation to a single IRMP decoder core for
the sigrok process to use. Multiple Python callers can synchronize their
library use, and see a consistent library state across the scope of the
context manager. It's essential though that callers leave the context
to not block other callers for extended periods of time.
|
|
|
|
|
|
The concurrent assertion of ATN and EOI is a PP (parallel poll) query.
The host asserts the control signals, and configured devices may assert
the DIO lines in response.
Because DAV is not involved, and because the input capture may not have
DIO at the start of the PP phase, and may neither have DIO any more at
its end, the check for parallel poll is more complex. Unconditionally
inspecting each sample of the capture is inefficient. Keep manipulating
the main loop's wait conditions instead, to stick with edge navigation
as long as possible, and only switch to inspection of individual samples
when strictly needed.
It's also important to gracefully handle low oversampling. Existing test
cases suffered from PP glitches when ATN asserted in the same location
where EOI deasserted. Be extra conservative about the presence of the
PP phase, expect at least two samples (a difference between its start
and end position) before emitting the annotation.
|
|
The description text of the Commodore peripherals option spanned a
rather wide space. Trim the text for consistency with other options.
|
|
HP gear is said to sometimes send commands (ATN asserted) with a parity.
Introduce an option to check and strip the MSB before interpretation.
Reported-By: Anders Gustafsson <Anders.Gustafsson@pedago.fi>
|
|
|
|
|
|
For now, libsigrokdecode clients expect to receive a 1:1 number of
input samples to logic output samples, along with a logic output
samplerate equal to the PD's input sample rate
|
|
This means that the samplerate for logic output channels is
implicitly determined by the input channel samplerate.
The motivation for this is that hard-coding a samplerate isn't
possible - but at the same time, it's also not possible to
determine the samplerate at the time the logic output channels
are initialized, as the samplerate can be set at runtime.
From my point of view, we would need one of two mechanisms to
make this work:
1) Allow creation of logic outputs at runtime via some
registration callback
or
2) Allow changing a logic output's samplerate after it has been
created, again requiring some kind of callback
To me, both currently are overkill because making the assumption
that samplerate_in = samplerate_out not only makes this problem
go away as it can easily be handled on the client side where
samplerate_in is already known, it also makes handling of the
logic data in the PDs easier.
|
|
|
|
|
|
"Un-clutter" the decode() routine. Group related instructions to improve
readability. Drop redundant statements where common code can handle all
cases. Also fixes an unconditional access to the optional decimal point
input signal (which had caused a runtime error, and ceased decoding).
|
|
Add a comment to the table which maps LED segment combinations to their
textual presentation. Mention the table's sort order for awareness, and
provide column captions as well as a segment layout illustration to
simplify maintenance.
The LED segment layout comment was
Submitted-by: Ben Gardiner <ben.l.gardiner@gmail.com>
|
|
Expand the list of characters that will be recognized by the seven
segment decoder to include many display character 'encodings.'
Including some punctuation characters and tricky letters like W and V.
Signed-off-by: Ben Gardiner <ben.l.gardiner@gmail.com>
[ gsi: sort by ASCII codes (keep ignoring letter case) ]
|
|
option show_unknown=yes will display unknown 7-segment characters as
an octothorpe ('#').
Signed-off-by: Ben Gardiner <ben.l.gardiner@gmail.com>
|
|
The 'parallel' decoder supported 32 channels when it was introduced.
Commit a3b4f1684a8f lowered the channel count to 8 which is quite a
small number. Increase the number of supported channels to 16 again.
This should result in increased usability while keeping an acceptable
UI dialog size for the decoder properties.
|
|
Update the decoder's doc string to catch up with recent extensions.
Rephrase how clock and data lines interact. Sparse assignment of data
lines is supported (has been for a while). Discuss the optional reset
signal and its enable/select use.
|
|
The parallel decoder documented the layout of the Python output but used
to emit something different (mere data values). Add the bit width of
data items and the bus cycle count for demultiplexed words, to match the
documented layout.
No harm was done, there are no in-tree decoders which stack on top of
the parallel decoder.
|
|
Straighten the accumulation of words from bit chunks that are spread
across several bus cycles (multiplexed transmission). Simplify the PD's
instance variables, keep more state in local vars and explicitly pass
related information to API calls. This also unobfuscates the emission
of annotations and simplifies future maintenance.
Split the accumulation of word data and the emission of its annotation
such that reset related activity can flush accumulated data. Introduce a
warning when word data gets emitted which does not match the configured
word width (early de-assertion of select/enable, or unexpected reset).
Presenting this data and amending it with a warning is considered more
desirable than not seeing the data at all. This does not affect previous
use cases since support for the reset signal was only introduced lately.
Also emit annotations in a more logical order. It's unexpected to see
the resulting word before its last item is seen. Graphical presentation
may not care but automated processing of the decoder output will. This
is the previous order of annotation emission which is surprising and got
fixed in this commit:
3768240-4118229 parallel: item: "3"
3768240-4468218 parallel: word: "33"
4118229-4468218 parallel: item: "3"
4468218-4818202 parallel: item: "3"
4468218-5268189 parallel: word: "32"
4818202-5268189 parallel: item: "2"
5268189-5368185 parallel: item: "2"
5268189-5568180 parallel: word: "28"
5368185-5568180 parallel: item: "8"
5568180-5668176 parallel: item: "0"
5568180-5868171 parallel: word: "08"
5668176-5868171 parallel: item: "8"
5868171-5968166 parallel: item: "0"
5868171-6168162 parallel: word: "01"
5968166-6168162 parallel: item: "1"
6168162-6268157 parallel: item: "0"
6168162-6468152 parallel: word: "0c"
6268157-6468152 parallel: item: "c"
This adjusted emission order won't pass the current test implementation,
but manual inspection of the output reveals that all the expected data
is present and matches previously extracted information:
parallel/hd44780_word_demux/annotation ..................................... Output mismatch
Testcase: parallel/hd44780_word_demux/annotation
Test output mismatch:
+ 4118229-4468218 parallel: item: "3"
- 4118229-4468218 parallel: item: "3"
+ 4818202-5268189 parallel: item: "2"
- 4818202-5268189 parallel: item: "2"
+ 5368185-5568180 parallel: item: "8"
- 5368185-5568180 parallel: item: "8"
+ 5668176-5868171 parallel: item: "8"
- 5668176-5868171 parallel: item: "8"
+ 5968166-6168162 parallel: item: "1"
- 5968166-6168162 parallel: item: "1"
+ 6268157-6468152 parallel: item: "c"
- 6268157-6468152 parallel: item: "c"
|
|
Add an optional 'reset' signal of user configurable polarity. When the
signal is asserted, the data lines are not interpreted. Assertion will
flush previously accumulated data bits and words. Deassertion can help
synchronize to input streams when the capture started in the middle of
a word. Despite the "reset" name this signal can also be thought of as
"enable" or "select", and increases the versatility and usefulness of
the parallel decoder beyond strictly parallel memory busses.
Construct the list of .wait() conditions and track the positions of
individual terms in that list. This is necessary because "always false"
conditions are not available, thus pin/channel indices and .matched[]
indices don't correspond for sparse input signal assignments.
Accept when previously gathered information became void again, and
re-use existing initialization code for reset related activity.
|
|
Add 'either' as another choice in addition to rising and falling clock
edge. This is useful since parallel busses exist which communicate at
double data rate (DDR).
Unobfuscate the mapping between displayed option text and .wait()
condition codes while we are here.
|
|
Strictly speaking this decoder considers all input signals as optional.
The previous version accepted clock alone. Though reading values from
zero data bits is of limited. Tighten the check for connected inputs.
Inline the declaration of all channels in the decoder boiler plate, the
helper routine was only used in a single spot. Change the order of the
data lines stripe details and the .wait() conditions, improve locality
of assignment and use of related variables.
Don't assume that "all channels but clock" are data lines. Use a
symbolic upper bound for the data lines partition, to prepare the
introduction of a reset/enable signal.
|
|
Concentrate tunables at the top of the source code. Eliminate magic
numbers by replacing them with symbolic identifiers.
|
|
The 0.652ms STOP bit width must have been a typo (though consistent in
the previous implementation), it's not half of the 1.125ms ZERO symbol.
Notice that this is an incompatible change to the decoder implementation.
It affects the annotations for STOP bits and overall REMOTE button codes.
|
|
Extend comments on the IR NEC timing details. Sort the symbols by their
width to reflect their relation (ONE to ZERO to STOP is each half of
their predecessor's width).
Increase the open coded tolerance percentage, and remove the option for
the value. Make sure leader and repeat codes still can be told from each
other.
|
|
Move IR NEC protocol timing details to the top of the source file, for
raised awareness and easier adjustment. Specs are "unit-less" (only have
comments), but are scaled for improved readability. Values are copies of
the previous implementation.
|
|
Provide an option to have the decoder automatically detect the IR signal's
polarity. Stick with active-low by default for backwards compatibility,
because this auto-detect implementation assumes that the capture starts
with an idle phase.
[ gsi: rephrased message and implementation, auto-detect off by default ]
|
|
Provide an option to adjust the IR NEC decoder's tolerance. Which makes
signals accessible that are generated by cheap remotes which would not
decode at all with the previous implementation and its fixed limit.
[ gsi: rephrased commit message and implementation ]
|
|
Emit annotations for the current IR frame as soon as possible, at the
very end of the STOP bit. Don't defer annotation emission until the
start of the next frame is seen. This unbreaks captures where the last
IR frame would not decode before.
[ gsi: rephrased commit message, updated comment in the implementation ]
|
|
The Joy-it SBC-IRC01 remote control appears as address 0x00.
|
|
Assume a maximum memory capacity, currently open coded, could become a
user servicable option when needed. Automatically flush the accumulated
outgoing data when a memory read reaches address 256.
Drop the unconditional START condition check now that it became obsolete.
|
|
The protocol is clocked, so strictly does not depend on the samplerate.
When the samplerate is available, the duration of internal processing
(memory erase and write) can get annotated. It's an optional feature.
The datasheet suggests that write and erase time are in the range of a
few milliseconds. Normalize to ms units and provide 10us resolution.
|
