| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Change client->server and server->client to be separately configurable,
allowing decoding at both the server (where client->server is RX and
server->client is TX) and client (where client->server is TX and
server->client is RX) ends of the link. It also allows monitoring of the
bus on a single channel (where client->server and server->client are both
RX (or TX)).
When I tried to decode a bus capture, I found that when the transmitter was
turned off it generated a false start bit, which in turn resulted in a false
trailing byte from the UART decoder. This narrowed the inter-frame gap to
the point where the Modbus decoder failed to recognise a new frame. The
result was only the first frame of the capture decoded - all the rest of the
frames failed to decode. I had to reduce the frame gap to allow subsequent
frames to decode, and so made it a configurable option that defaults to the
existing gap.
Lastly, I fixed a call to puti() that incorrectly included the annotation
prefix.
|
|
This fixes bug #1376.
|
|
This fixes bug #1377.
|
|
From a protocol level, a BULK IN transfer starts when the host starts
polling the respective endpoint. For analysis, it is sometimes useful
to show when the devices starts to answer the requests.
As both are useful for different use cases (the old, default one emphasizes
the host behavior, the new one shows the endpoint/device behavior), make
the display configurable.
|
|
E.g. CONTROL and BULK IN transfers may overlap each other, and as a result
only one of the two can be seen in pulseview.
Partly solves bug #1046. In case a device has multiple IN/OUT endpoints,
transfers would still overlap, but many simple devices have just one each.
|
|
Append OUT data only if it has been ACKed. OUT transfers (BULK OUT or
CONTROL transfer DATA stage) are typically NACKed to create backpressure.
Always keep IN and OUT transfers separate. On the physical layer, the
endpoint number only uses 4 bits, and IN and OUT use separate tokens.
In case the transfer is an IN transfer, set the high bit as used in the
endpoint descriptors (i.e. 0x81 is IN enpoint 1, 0x01 is OUT endpoint 1).
|
|
(for consistency with all other decoders)
|
|
|
|
|
|
|
|
This makes it more consistent with the rest of the decoders.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
executed in Validate mode.
|
|
|
|
|
|
Use the same (more logical) order of having the "bits" annotation row
being the first one, which is also what pretty much all other PDs do.
|
|
|
|
There is already an OUTPUT_PYTHON type named 'TRANSFER' that is being
transmitted to stacked decoders. Make the same information available
as annotations (additionally), which can be helpful in some situations.
|
|
|
|
The format "0xAA BB CC ..." looks a bit strange, use "AA BB CC" instead,
it's relatively obvious that the data is hex-encoded.
The quotation marks around some names/values are unneeded and reduce
readability a bit, so drop them.
|
|
|
|
By using the annotation strings as command names directly, some parts
of decode_command() can be simplified a bit.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
