Martyn wrote:...all feedback on serial decoding is welcome.
Serial decoding of data that is already packetized (CAN, Flex-ray, etc.) is comparatively easy. Handling arbitrary byte streams, and partitioning them properly into packets is harder, but is almost always significantly more useful than the raw byte stream. I've commented on this before, in other threads, but will go into a bit more detail.
There are 5 (or 6) generally used methods for achieving this:
1) the Idle-time
threshold that Fullboar refers to. Bytes that are "close together" are collected into an aggregated packet, and split at points that exceed a user-defined idle-time threshold.
2a) Fixed length
. Packets always contain the next N bytes.
2b) Embedded length
. The length info is contained at a specific offset within the header section of the packet. Many ISO protocols implement this mechanism.
3) Start delimiter.
Every packet beginning is marked by some specific pattern. This may be a full-byte value (or values), or a specific nibble in a byte, so a masked comparison may be required.
4) End delimiter.
Similar to the Start delimiter.
. Sometimes the start/end flagging is indicated by the presence of a high-order bit, when the remaining contents doesn't need to use the entire byte. This is a variation of a bit-masked Type 3, so perhaps shouldn't be listed separately.
Sometimes, for the sake of redundancy (to improve robustness), methods get combined. (Proprietary protocols I've defined in the past have combined (3) and (2b), for example, to enable Resync to be obtained after a corrupted packet header.)
The key thing to keep in mind when shifting to a packet-structured List Mode is that inter-byte stats (on each byte) will be lost. Though it would be possible to report min/max stats (at EOP) to replace those. However, in almost all situations, the value of seeing an entire packet in context greatly outweighs any info losses on the individual byte level.
~~Next in line, right behind this, is the ability to see a two-way "conversation", where Transmit/Receive interactions (from 2 separate sample Channels) are visible in the same context (List), without having to flip back & forth to another window or Tab.
In almost every full-duplex comms-bus environment I've worked in (UARTs=Tx+Rx, SPI=MISO+MOSI, etc.) this is a really fundamental
capability. It's difficult to overestimate the increase in productivity that such a capability can make. (Or how much it's absence negatively impacts the same, while contributing to operator frustration.) Almost all stand-alone desktop scopes I'm aware of get this right (each decoder has enough channels to handle the correlated comms-channel pairs).