The Logic Sniffer's extended SUMP protocol
In addition to the SUMP protocol, the Logic Sniffer also has some custom protocol extensions.
- 0x03 - A self test mode can be triggered with 0x03.
0x03 starts a test pattern output on the unbuffered pins. When connected to the buffered pins you can view the pattern with a logic analyzer capture.
This should be expanded with images of the self-test with the Java client update. Maybe a separate section for the self-test overview?
Bit 11 of the flag settings - Internal test pattern mode (supplies data internally)
- 0x05 - finish now. End the current RLE capture by sampling to the end immediately, then dump the samples
The Verilog core has some bonus rle modes, selected by bits 15:14 of the flags register. The modes are:
- 0 = Issue <values> & <rle-count> as pairs. Count inclusive of value. Backwards compatible.
- 1 = Issue <values> & <rle-count> as pairs. Count is -exclusive- of value.
- 2 = Periodic. <values> reissued approx every 256 <rle-count> fields.
- 3 = Unlimited. <values> can be followed by unlimited numbers of <rle-counts>.
Default is 0. Higher modes all use exclusive counts. Mode 2 gives robustness & approx. doubles storage of non-changing values. Mode 3 really maxes out storage, but if the initial value is lost, you have problems. Source.
A new command byte is added to the sump protocol: 0x04 - get metadata. In response, the device sends a series of 1-byte keys, followed by data pertaining to that key. The series ends with the key 0x00. The system can be extended with new keys as more data needs to be reported.
Proposed meta data format
The keys are split up into two fields: the upper 3 bits denote the type, and the lower 5 bits denote the token. The token is unique within the type. Thus a 0x01 null-terminated string token is not the same as a 0x01 integer token.
This way a client need only know about the keys it can deal with, while still having a way to skip over the ones it doesn't know -- since the type field denotes a length (or null-terminated field). If more metadata keys get added in the future, clients will just ignore them until support for those keys is added to the application.
This means a client parsing metadata MUST always ignore keys it doesn't know, never give an error message for them.
|0||null-terminated string, UTF-8 encoded|
|0||0x00||not used, key means end of metadata|
|1||0x01||device name (e.g. "Openbench Logic Sniffer v1.0", "Bus Pirate v3b"|
|2||0x02||Version of the FPGA firmware|
|3||0x03||Ancillary version (PIC firmware)|
|1||32-bit unsigned integer|
|0||0x20||Number of usable probes|
|1||0x21||Amount of sample memory available (bytes)|
|2||0x22||Amount of dynamic memory available (bytes)|
|3||0x23||Maximum sample rate (hz)|
|4||0x24||Protocol version (see below)|
|2||8-bit unsigned integer|
|0||0x40||Number of usable probes (short)|
|1||0x41||Protocol version (short)|
There's probably quite a bit more that would be interesting to support (please add to the list).
The protocol version key holds a 4-stage version, one per byte, where the MSB holds the major version number. As of the first release to support this metadata command, the protocol version should be 2. This would be encoded as 0x00000002.
The 8bit short commands are an alternative to the 32bit commands for number of probes and version. This saves space on a small systems. Most systems are unlikely to sport more than 256 probes, so there's no reason to store 3 null bytes. A client should support both.
Arm advanced trigger (0x0F)
Write trigger select (0x9E)
Write trigger data (0x9F)
Send it 5 times to make sure you're clear of any partial long commands.
Start capture or arm trigger.
Query ID (0x02)
Returns 1ALS in all known versions.