| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
On some platforms PY_FORMAT_SIZE_T seems to be ineffective, resulting in
compiler warnings about printf format data type mismatches (observed in
MXE builds).
Silence the warnings. Prefer the ssize_t data type instead which we know
the printf format of, reliably.
|
|
Silence printf(3) format warnings. Python's data types should be
considered opaque, size (and signedness) are usually unknown, as is
the relation to standard C language print format specs.
Unbreak long messages which were spread across several source code
text lines. This complies to Linux style guides. Being able to find
diagnostics messages that were reported by users in sources is more
important than sticking to an arbitrary text line length.
|
|
Break a rather long line for a Python method call at a different
location, to better reflect the parameter groups which organize for the
method to get called, and those which pass parameters to that called
method. This commit also splits the actual action and its check for
successful execution into separate C language statements.
|
|
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.
|
|
When the protocol decoder's input data is exhausted, then the .wait()
method will raise the EOFError exception. Python decoders can catch this
exception and handle the condition. For proper annotation emission it is
essential that the self.samplenum value corresponds to the last position
in the input stream. Update it before returning from the .wait() call.
|
|
The optional SIGROKDECODE_DIR environment variable accepts a single
directory specification. The SIGROKDECODE_PATH variable accepts a list
of directories to search protocol decoders. The list separator is
platform dependent (colon or semicolon). Empty items are explicitly
ignored. Both variables get evaluated. Behaviour remains backwards
compatible, just gets extended for improved usability.
|
|
A comment in the srd.c implementation suggests that the environment
variable SIGROKDECODE_DIR would serve debugging purposes and would
override other incarnations of available decoders. I disagree with
either of these interpretations. Add a TODO comment, the phrase may
need an update or rework.
|
|
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).
|
|
Add the __declspec(dllexport) decoration to SRD_API routines on Windows
when building the library body (this is new). Stick with the default
visibility on all other platforms (as previously implemented).
This is similar to what Kyle Johnson submitted in PR 66, but phrased
differently. Avoid the non-portable indentation before the hash in
preprocessor instructions. Use positive logic for readability (put
the Windows branch next to the check for the Windows platform).
Reported-By: Kyle Johnson <KyleJ61782@gmail.com>
|
|
Use longer variable names for the iteration over channels, options,
annotation classes and rows, and binary classes when a decoder gets
loaded. This improves readability, especially in nested loops with
complex test conditions and diagnostics messages.
Although the Python variables were checked for their availability and
expected data type, and we should only see non-negative index values,
the iteration variable's data type remains unchanged in this commit
(sticks with signed size types).
|
|
Check the annotation class indices when iterating annotation rows.
Refuse to load decoders with inconsistent declarations, emit error
messages to raise developers' awareness of implementation bugs.
This fixes bug #1601.
|
|
Don't break long error messages in source code, so that developers can
grep for user reported strings during maintenance. This commit does not
change behaviour.
Concentrate repeated references to the 'annotation_rows' Python variable
name in a single spot at the top of the helper routine.
|
|
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 IRMP core library is not thread safe (known limitation, heritage of
the AVR firmware origin). Add a mutex so that calling applications can
lock IR decoder core instances. Allow Python threading while waiting for
the locks, we can safely assume that this IRMP wrapper is used in the
sigrok context which does require Python for decoders. Add my copyright
for the non-trivial changes.
This implementation uses glib for locking to improve portability, which
already is a dependency of the libsigrokdecode component. This version
uses belt and suspenders by implementing a constructor as well as adding
auto init calls to each of the public API code paths. The client ID is
not an essential requirement, but useful during application maintenance.
|
|
Platform detection in the external IRMP library works best when either
the WIN32 or the unix identifiers are provided, which the sigrokdecode
build environment derives from other identifiers which are more reliably
available.
It turns out that other external dependencies like glib or Python may
provide some of these identifiers, too. Which results in the compiler
warning about symbols' redefinition. Only define derived identifiers
when they haven't been provided yet.
This amends commit ab88bae1c7b9.
|
|
Introduce the public srd_session_send_eof() routine which is backed by
the internal srd_inst_send_eof() helper. Applications can tell decoders
when the input stream of sample data is exhausted, so that decoders can
optionally "flush" their previously accumulated information when
desired. Previous implementations just kept decoders in blocking .wait()
calls and somehow terminated them at arbitrary times afterwards.
When EOF is sent to the decoder session, then calls to the .wait()
method which typically are done from .decode() or its descendents will
end with an EOFError Python exception. Termination of .decode() with the
EOFError exception is non-fatal for backwards compatibility and to keep
the convenience for current decoder implementations. Decoders can either
catch the exception, or use context managers, or do nothing.
This API extension is motivated by research for bug #1581 and provides
the infrastructure to address bug #292. Decoders need to remain careful,
and should not claim that protocol activities would have completed when
their end condition was not even seen in the capture. Marking incomplete
activities with warnings is the most appropriate reaction.
|
|
Rephrase the 'names[]' array declaration in output_type_name() to avoid
the necessity of guessing what the maximum length of the literals might
be during future maintenance. Developers need not care when the compiler
can handle this detail.
|
|
Avoid the full listing of all-zero struct members in sentinel items of
object methods and class properties tables. Use the ALL_ZERO phrase
instead which better reflects what's intended, and reliably silences
warnings should structs' lengths differ across Python versions.
|
|
Some doc strings have become outdated, update them. Some doc strings
were terse, extend them. Ideally protocol decoder authors would be able
to use the builtin documentation to answer questions on data types and
arguments order. This implementation isn't there yet, needs more work.
|
|
Move Python doc strings to the location where methods and classes get
implemented. This improves awareness during maintenance, and allows for
longer text phrases without obfuscating the registration code path.
This commit does not alter the content of existing doc strings, only
moves their location. And keeps related items together when long decls
span multiple text lines (function name and arguments list, args and
kw args), to improve/keep readability.
|
|
Declare ALL_ZERO in the common libsigrokdecode-internal.h header file.
The implementation and the comment on its motivation were taken from the
libsigrok implementation, slightly rephrased for improved readability.
|
|
This provides some future-proofing against newer Python versions.
|
|
|
|
|
|
|
|
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>
|
|
|
|
This fixes bug #1671.
Reported-By: Ivan Wick
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
Protocol decoders can now declare an arbitrary number of logic output
channels with a fixed assumed samplerate each.
|
|
"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.
|
