| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Annotations generated by the onewire_network decoder started where bit 1
began, while it should align with the start of bit 0.
|
|
Getting the first edge outside of the loop in .decode() greatly
simplifies the logic, any other edge then is just an update of the
previously collected data, determined by always equal code.
|
|
The previous implementation of the I2C decoder used to retrieve and not
process the first sample of the input stream. Remove this instruction.
|
|
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.
|
|
The Decoder.wait() method expects a list of dicts, or as a special form
a single dict, to specify the conditions to wait for. An empty dict or
an empty list mean "unconditional wait", requesting the very next sample.
Accept None as well as no arguments at all in Decoder.wait() calls. This
shall better reflect the intent and slightly unobfuscate PD code, as well
as avoid creation of potentially expensive Python objects at the call site.
|
|
The Decoder.wait() method works as expected when non-empty conditions
are specified by the caller. For empty conditions the implementation was
incomplete, and ended up in an infinite loop because the sample number
got stuck in the current location. Code review revealed more issues like
not getting more input data chunks when needed.
Detect when empty wait() conditions were specified, and re-use existing
code paths for match handling as much as possible. This is achieved by
the manual creation of a SKIP term with the appropriate count value.
It's assumed that naive decoder implementations will run this kind of
condition-less query for every individual sample, which means that
efficiency is important.
Make sample number 0 available to condition-less calls, too. Don't skip
the first sample in the input stream.
|
|
Rephrase how the 'WAIT IDLE' stage skips over all-low input signals.
Have the next high level on either line detected in common code.
|
|
Do reference the period's start and end sample numbers when the
duty cycle is written to the binary output stream. The previous
implementation inappropriately used the period counter instead.
|
|
Move more items from the Python object's members to local variables of the
decode() method, as they are used there exclusively.
Mark a spot where the binary output references suspicious "sample numbers".
|
|
With the simplicity of PWM waveforms and the convenience of the v3 API,
there is no need to maintain internal state. After the start of the
first period was determined based on the input signal's polarity, any
period is defined by just the next two edges, and the next period is
immediately to follow.
|
|
All decoders must be of PD API version 3 now.
|
|
This is not really relevant for stacked PDs currently (they can be used
unmodified with either PDv2 or PDv3 low-level decoders), but it'll allow
us to drop PDv2 support completely.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
session.c:203:22: warning: format specifies type 'unsigned long long'
but the argument has type 'guint64' (aka 'unsigned long') [-Wformat]
sess->session_id, g_variant_get_uint64(data));
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
libsigrokdecode-internal.h:103:44: note: expanded from macro 'srd_dbg'
#define srd_dbg(...) srd_log(SRD_LOG_DBG, __VA_ARGS__)
^~~~~~~~~~~
|
|
0.6.0 will be the next major release. Bump now, so that
there is no confusion of tarball 0.5.0 and 0.6.0-git snapshots.
|
|
The last release (0.4.0) had the libtool version (current:revision:age)
set to 3:0:0. Since this release removes and changes interfaces, the
new version is 4:0:0.
http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
This changes the library filename (e.g. on Linux) from
libsigrokdecode.so.3.0.0 to libsigrokdecode.so.4.0.0, the SONAME
(+symlink) becomes libsigrokdecode.so.4.
|
|
|
|
|
|
Check for the availability of a samplerate specification, but don't
abort in its absence. Lack of the samplerate only prevents the emission
of throughput annotations, but still allows decoding the clocked signal.
|
|
Eliminate more instances where Python code tracked signal changes instead
of having common library code do the work. Reduce the number of boundary
crossings between library and decoder code (Python vs C), by inspecting
fewer input edges. Yet cope with the CS signal's being optional. Emit
identical annotations to the previous implementation for CS changes,
including the initial change "from None to 0/1". Sort the checks for
optional input signals at the top of decode() into a more natural order.
Improve and update comments.
This commit results in a more appropriate use of the PD v3 API in the
SPI protocol decoder.
|
|
Have edges detected in common library code. Cope with optional initial
low level (without an edge) at the start of sample data. Handle the
optionally enforced processing at a specified sample number.
|
|
Have edges detected in common library code.
|
|
Have edges detected in common library code. Move the test for presence
of optional channels out of the decode loop. Do inspect the very first
sample for pixel compatibility with the previous implementation.
|
|
|
|
Not all EEPROMs of this series have (just) a 'c' in the name.
|
|
|
|
|
|
This allows frontends to set the assumed initial pins (i.e., the assumed
state of the pins before the first sample of a capture) to user-specified
values.
The assumed initial pins can be either low, or high, or "use same value
as the first sample of the capture".
The special self.initial_pins decoder attribute is now removed.
|
|
None of the other PDs have a vendorname in the PD name.
|
|
|
|
|
|
Bit stuffing does not apply to the last fields of a frame, specifically
the CRC delimiter, the ACK, and the end-of-frame fields. Adjust the
respective bit handling logic.
This fixes bug #656.
|
|
Don't inspect each individual sample in the Python based PD. Instead use
the backend's query API to detect the start of a frame and to advance to
the sample point position.
|
|
|
