| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This can be used by frontends for decoder search features.
|
|
|
|
Introduce an 'ieee488' protocol decoder which handles both the 16 lines
parallel GPIB variant as well as the serial IEC bus variant. Which kind
of supersedes the 'gpib' and 'iec' decoders.
This implementation increases maintainability because only the extraction
of raw bytes from the parallel or serial bus is separate, and all GPIB
related command/address/data interpretation is shared. This decoder extends
the feature set of the previous versions: Visual annotations are more fine
grained (more classes, additional rows, various text lengths to maintain
usability during zoom). There is binary output for communicated data,
as well as Python output for stacked decoders. Consecutive runs of
talker data gets accumulated, and is made available in binary form as well
as text (with escapes for non-printables). The terse single-letter format
(character codes '0' to 'O' for addresses) is kept for compatibility for
those users who are accustomed to it. The implemented logic also copes
with captures of low samplerate, where edges happen to fall onto the same
sample number which at higher samplerates shall be perceived as distant
and should get processed in their respective order of appearance.
This implementation tracks the most recent configuration of "peers" (the
set of talkers and listeners). A future implementation might support the
isolation of a single conversation out of a busy chat on the bus.
Some optional support for Commodore peripherals is included (currently
limited to disk channels), while it's recommended to move this logic to
a stacked decoder if it grows more complex.
|
|
|
|
|
|
|
|
This avoids floating point number option values, which makes things
a bit easier/clearer on the command-line and also matches what other
decoders do.
Also, use numbers instead of strings for the option values.
|
|
|
|
|
|
|
|
This makes the decoder a lot nicer to use from the command-line.
* num_data_bits -> data_bits
* parity_type -> parity
* num_stop_bits -> stop_bits
* rx_packet_delimiter -> rx_packet_delim
* tx_packet_delimiter -> tx_packet_delim
|
|
Rephrase the test for the availability of at least one of several
optional input signals, and reword the corresponding error message.
|
|
The previous UART decoder implementation announced a 'check_parity'
option which took no effect (support code was missing). Remove it. Add
another 'ignore' parity choice instead, which consumes the parity bit's
position yet always passes the check.
|
|
|
|
Generally show "bits" and other smaller annotations in rows that come
before "larger" annotations (in later rows).
|
|
|
|
|
|
Do more of the calculation with floating point, only trim precision and
enforce integers at the end of the determination of the next sample
point. This shall increase robustness at low capture sample rates.
|
|
|
|
|
|
|
|
Without this, e.g. the recently added 'IDLE' ptype of the UART decoder
would cause issues.
|
|
|
|
Detect periods of a frame's length with idle level, and communicate
these time spans to stacked decoders by means of PYTHON output. Do *not*
display these idle frames in regular annotations, for backwards compat.
|
|
|
|
|
|
|
|
|
|
|
|
The gpib decoder tried to "flush" input data at a user specified sample
number when the input data lacked the respective edge which triggers the
processing during regular operation.
This is rather obscure a feature, not seen in any other decoder, perhaps
a workaround for bug #292, rather unaccessible to users (units of sample
numbers not times nor automatic detection of the EOF condition), highly
confusing according to user reports, and not covered by existing tests.
The mere presence of this option caused severe issues in application
code (see bug #1444). While there is no apparent fix that won't affect
other decoders. So let's drop this questionable feature. Valid and
complete captures should contain all relevent edges and thus decode
properly.
|
|
A recent commit tightened the check for acceptable 'skip' sample counts.
This broke the onewire_link and usb_signalling decoders' test sequences,
which no longer pass with a minimum count of one. Relax the condition
and accept a count of zero. This breaks gpib again for low total sample
count option values, but this needs to get addressed differently.
|
|
Introduce an "always false" type for .wait() terms. Map invalid counts
of skip conditions (zero or negative numbers) as well as invalid channel
references for level/edge conditions to this type which never matches.
Keep this "always false" term type an internal detail of the common
support code.
This is most robust and least intrusive at the same time, it keeps the
existing API, and simplifies the implementation of Python decoders for
rare edge cases (optional input signals or optional features, handling
of initial samples at the very start of a capture).
This commit passes sample counts internally in a signed data type. This
is essential for proper operation, and the loss of one bit out of 64
shall not be considered a severe limitation.
This fixes bug #1444.
|
|
|
|
|
|
|
|
|
|
This is a protocol decoder for the 'ASCII' protocol used by
Amulet Technologies LCDs.
Currently some commands are not implemented yet. I also lack capture data
from a display that will use replies other than ACK and NACK.
Reads are untested as I have no suitable captures.
The PD copes with bus errors (there is an actual bug in the device I'm
reverse engineering) and most of the commands are implemented.
The unimplemented commands should generally consume the correct
number of bytes from the bus, the exception to this are the drawing
commands, because there are actually at least two revisions of them
with different payloads, that are really hard to detect in greedy
algorithm.
|
|
instance.c:62:2: runtime error: null pointer passed as argument 1, which is declared to never be null
instance.c:858:45: runtime error: shift exponent -1 is negative
instance.c:836:45: runtime error: shift exponent -1 is negative
|
|
We currently use a mix of Py_IncRef/Py_DecRef and Py_XINCREF/Py_XDECREF
or Py_INCREF/Py_DECREF in the code-base. Only use the latter variants
for the time being (for consistency).
|
|
These were reported when compiling with "-fsanitize=address" and running
"PYTHONMALLOC=malloc make check":
=================================================================
==42879==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 317 byte(s) in 6 object(s) allocated from:
#0 0x7f08e4809538 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7f08e3f37622 in PyUnicode_New ../Objects/unicodeobject.c:1365
Direct leak of 28 byte(s) in 1 object(s) allocated from:
#0 0x7f08e4809538 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7f08e3f7e1a5 in _PyLong_New ../Objects/longobject.c:275
Direct leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f08e4809538 in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cc:144
#1 0x7f08e3f91521 in PyFloat_FromDouble ../Objects/floatobject.c:122
SUMMARY: AddressSanitizer: 369 byte(s) leaked in 8 allocation(s).
session
|
|
|
|
|
|
|
|
This fixes bug #1374.
|
|
|
|
Similar to the recently added [rx|tx]_packet_delimiter options, these
emit summary annotations ("packets") when a certain number of data values
have been decoded.
This is a convenience feature which can be useful when a user wants to
view data which doesn't have a specified delimiter value (as last data
value in the "packet"), but rather fixed-length "packets".
This is just an (intentionally very simple) helper/convenience improvement
and is NOT meant to replace "proper" stacked decoders for UART-based protocols.
|
|
This is a convenience feature that emits summary annotations ("packets")
that comprise all data values that were decoded until a specified delimiter
value is seen (as last data value of the "packet").
Example use-cases include ASCII data where it can be convenient to
"packetize" whenever a 10/0x0A value (newline) is seen, or some
protocols which have a fixed "marker" value (e.g. 0x55) as last
value in the "packet".
The annotations are affected by the selected 'format' option, i.e. the
user can get summaries in ASCII or hex or other formats.
This is just an (intentionally very simple) helper/convenience improvement
and is NOT meant to replace "proper" stacked decoders for UART-based protocols.
|
|
This fixes bug #1438.
|
|
This improves readability a bit in most cases.
|
