| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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 improves readability a bit in most cases.
|
|
|
|
|
|
|
|
There are various different names that these types of memories are being
referred to in the wild: SPI flash, flash chip, flash, flash EEPROM,
SPI EEPROM, serial flash, serial memory, flash memory, and various others.
In order to make UI decoder selection more useful to the user, we add
the "EEPROM" string to some of the decoder metadata fields, so the
decoder will (for example) show up in PulseView's list of decoders when
the user types "eeprom" to narrow down the listed decoders.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
