Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
This fixes the remaining parts of bug #1365.
|
|
|
|
|
|
The official abbreviation for CMD24 in the spec is "WRITE_BLOCK", as
opposed to "WRITE_MULTIPLE_BLOCK" for CMD25 (chapter 4.7.4,
"Detailed Command Description", table 4-24).
The byte preceeding e.g. the CMD24 block data is called "Start Block" token
(chapter 7.3.3.2, "Start Block Tokens and Stop Tran Token"). We don't
include the "token" itself for consistency, since the decoder doesn't do
that for any other tokens either.
|
|
Address some nits in the SDCard (SPI mode) protocol decoder. Rename
identifiers to eliminate comments. Determine the default block size at
the start of the write command instead of the iteration over payload
data bytes. Remove a print() statement which would break regression
tests. Allow re-use of the data handler for other commands, too. Use
lower case hex digits for consistency across the source file, and
slightly unobfuscate a bit pattern check while we are here. Improve
robustness of response handlers and how internal state gets advanced.
Replace constant lookups by direct method calls.
|
|
The previous implementation advanced from the start of CMD24 to IDLE.
This commit introduces support for the data phase and data response of
CMD24. Which results in improved usability of the decoder output, and
reduced probability of false positives (don't detect "commands" in the
payload data).
This commit addresses the missing CMD24 handling part of bug #1365.
|
|
Currently there must be at least one match of inputs/outputs for
decoders that are stacked. If not, we emit an informational warning
(but this is not a hard error for the time being).
|
|
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.
|
|
|
|
This is a 1-Wire 8-channel addressable switch.
|
|
For details see the DS2408 datasheet, section "Power-up timing".
This commit is adding this missing command so now a full decoding
is possible:
Annotations from 1-Wire network layer:
8990980-8991220 1-Wire network layer: : Reset/presence: true
8994163-8994437 1-Wire network layer: : ROM command: 0x96 'DS2408: Disable Test Mode'
8995026-9008178 1-Wire network layer: : ROM: 0xa30000001246a929
9008785-9009060 1-Wire network layer: : Data: 0x3c
9012290-9012530 1-Wire network layer: : Reset/presence: true
And from the specific stacked DS2408 slave:
8990980-8991220 DS2408: : Reset/presence: true
8995026-9008178 DS2408: : ROM: 0xa30000001246a929 (family code 0x29)
9008785-9009060 DS2408: : Disable Test Mode (0x3c)
9012290-9012530 DS2408: : Reset/presence: true
|
|
For details see the DS2408 datasheet, section "Resume Command [A5h]".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
screen" from functioning
Source: https://en.wikipedia.org/wiki/RC-5#Command_Tables
|
|
|
|
- Square wave frequencies above 1 Hz are in Hz not in kHz.
- AM/PM flag is in the bit 5 of hours register not in bit 6.
- AM flag is valid at 0 value of AM/PM flag not at 1 value.
|
|
The "Frame error?" TODO comment on Python annotations has become
obsolete. Individual bit errors within the frame immediately get
communicated as they are detected (START, parity, STOP). The overall
frame's validity has become available with the FRAME annotation.
|
|
Internally keep track of the UART frame's validity. Emit a FRAME Python
annotation for aborted as well as for completed frames. This obsoletes a
TODO comment in the STOP bit code path.
This annotation also spans the complete frame's length, including start
and parity and stop bits, which the DATA annotation doesn't cover.
Stacked decoders can individually decide whether to strictly reference
the mere data bits section or the complete UART frame which happened to
communicate the data value.
|
|
|
|
1. WS = 0, Left Channel; WS = 1, Right Channel
2. Data start and end at falling edge of SCK
|
|
|
|
|
|
|
|
|
|
In theory support for PD reset is optional, applications are not
required to make use of it. But it's essential to receive correct
decoding results when used with the popular Pulseview mainline
application.
So let's consider the absence of the reset() method fatal. All mainline
decoders have it. Out-of-tree decoders are easy to adjust, and very
probably should support reset() as well. Thus this change is considered
beneficial, and not harmful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Minimal implementation of chip erase 0x60 and 0xc7 command handling
|
|
|
|
==187759== 88 (40 direct, 48 indirect) bytes in 1 blocks are definitely lost in loss record 2,262 of 3,218
==187759== at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==187759== by 0x563C435: g_malloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==187759== by 0x5654056: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==187759== by 0x5673630: g_variant_new_from_bytes (in /usr/lib64/libglib-2.0.so.0.5600.3)
==187759== by 0x566C5E6: ??? (in /usr/lib64/libglib-2.0.so.0.5600.3)
==187759== by 0x566C7D2: g_variant_new_uint64 (in /usr/lib64/libglib-2.0.so.0.5600.3)
==187759== by 0x403D41: conf_check_fail.constprop.6 (session.c:152)
==187759== by 0x403E06: test_session_metadata_set_bogus (session.c:215)
==187759== by 0x53E51D5: srunner_run_tagged (in /usr/lib64/libcheck.so.0.0.0)
==187759== by 0x401237: main (main.c:51)
|
|
==187724== 917 bytes in 1 blocks are definitely lost in loss record 3,046 of 3,207
==187724== at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==187724== by 0x563C435: g_malloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==187724== by 0x5655D82: g_strdup (in /usr/lib64/libglib-2.0.so.0.5600.3)
==187724== by 0x4E43937: py_str_as_str (util.c:371)
==187724== by 0x4E415E1: srd_decoder_doc_get (decoder.c:892)
==187724== by 0x40281D: test_doc_get (decoder.c:395)
==187724== by 0x53E51D5: srunner_run_tagged (in /usr/lib64/libcheck.so.0.0.0)
==187724== by 0x401237: main (main.c:51)
|
|
==175453== 522 bytes in 8 blocks are definitely lost in loss record 2,923 of 3,201
==175453== at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==175453== by 0x59E9BB5: PyObject_Malloc (in /usr/lib64/libpython3.6m.so.1.0)
==175453== by 0x5A35A76: PyBytes_FromStringAndSize (in /usr/lib64/libpython3.6m.so.1.0)
==175453== by 0x4E3FA6E: print_searchpaths (srd.c:173)
==175453== by 0x4E3FA6E: srd_init (srd.c:287)
==175453== by 0x4034BE: test_session_reset_nodata (session.c:238)
==175453== by 0x53E51D5: srunner_run_tagged (in /usr/lib64/libcheck.so.0.0.0)
==175453== by 0x401237: main (main.c:51)
|
|
When the decoder and session unload functions are called they
remove themselves from the list. The code walking the list
must be careful to avoid accessing the next pointer which
might now be invalid. The g_slist_foreach() takes care of
this.
Reports from Valgrind before fix:
==175436== Invalid read of size 8
--
==175436== Address 0xe3f2598 is 8 bytes inside a block of size 16 free'd
==175436== at 0x4C2FDAC: free (vg_replace_malloc.c:530)
==175436== by 0x563C541: g_free (in /usr/lib64/libglib-2.0.so.0.5600.3)
==175436== by 0x5654783: g_slice_free1 (in /usr/lib64/libglib-2.0.so.0.5600.3)
==175436== by 0x56552A2: g_slist_remove (in /usr/lib64/libglib-2.0.so.0.5600.3)
==175436== by 0x4E3FEFF: srd_session_destroy (session.c:343)
==175436== by 0x4E3F5C7: srd_exit (srd.c:311)
==175436== by 0x40336F: test_inst_new (inst.c:40)
==175436== by 0x53E51D5: srunner_run_tagged (in /usr/lib64/libcheck.so.0.0.0)
==175436== by 0x401237: main (main.c:51)
==175436== Block was alloc'd at
==175436== at 0x4C2EBAB: malloc (vg_replace_malloc.c:299)
==175436== by 0x563C435: g_malloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==175436== by 0x5654056: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.5600.3)
==175436== by 0x5655797: g_slist_append (in /usr/lib64/libglib-2.0.so.0.5600.3)
==175436== by 0x4E3FC75: srd_session_new (session.c:71)
==175436== by 0x403345: test_inst_new (inst.c:37)
==175436== by 0x53E51D5: srunner_run_tagged (in /usr/lib64/libcheck.so.0.0.0)
==175436== by 0x401237: main (main.c:51)
|
|
Drop @since tags for non-public functions.
|