Difference between revisions of "Feeding hardware-decoded packets into libsigrok"
(Created page with "Soeren Abel came up with an interesting use-case: The yokogawa DLM2000 series can do I2C decoding on the device, and feed the I2C packets and associated metadata to an SCPI c...") |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
Soeren | Soeren Apel came up with an interesting use-case: | ||
The yokogawa DLM2000 series can do I2C decoding on the device, and feed the I2C packets and associated metadata to an SCPI client: | The yokogawa DLM2000 series can do I2C decoding on the device, and feed the I2C packets and associated metadata to an SCPI client: | ||
| Line 28: | Line 28: | ||
== Other scopes that can send decoded data over SCPI == | == Other scopes that can send decoded data over SCPI == | ||
... | Keysight InfiniiVision 3000 X-Series Oscilloscopes and | ||
Agilent InfiniiVision 7000A Series Oscilloscopes: | |||
:LISTer:DATA | |||
Query Syntax :LISTer:DATA? | |||
The :LISTer:DATA? query returns the lister data. | |||
Return Format <binary block><NL> | |||
<binary_block> ::= comma-separated data with newlines at the end of each row | |||
== RS232 == | |||
* One or two serial ports could be used as a "poor man's capture device" to decode RS232. The communication parameters for RS232 would have to be known to capture, the higher level protocol could then be analyzed with lsrd. | |||
* The output of a program like [http://www.suspectclass.com/sgifford/interceptty/ interceptty] could be converted into the sigrok format and then be analyzed. No need to hook up any probes. | |||
Both use cases could be useful if no "real" logic analyzer is available or for debugging. | |||
Latest revision as of 15:46, 23 December 2014
Soeren Apel came up with an interesting use-case:
The yokogawa DLM2000 series can do I2C decoding on the device, and feed the I2C packets and associated metadata to an SCPI client:
:SERialbus<x>:I2C:DETail:LIST:ITEM? Queries all items that will be displayed in the I2C bus signal analysis result list. Example :SERIALBUS1:I2C:DETAIL:LIST:ITEM? -> "No.,Time(ms),1st,2nd,R/W,Data,Information" :SERialbus<x>:I2C:DETail:LIST:VALue? Queries all of the data for the specified analysis number in the I2C bus signal analysis result list. Example :SERIALBUS1:I2C:DETAIL:LIST:VALUE? 0 -> "0,-0.07000,AA*,,W,AE*88*,7-bit"
This hardware-level decoder has access to more raw data than device ever feeds to sigrok: it cannot stream continually via SCPI transports, for example. So it's entirely possible, even likely, that the hardware can decode more I2C data from the raw signal than libsigrok/libsigrokdecode ever could.
Thus, this is a use-case for getting I2C packets from the hardware, associating it with libsigrok timing reference (sample numbers) and feeding to libsigrokdecode as an I2C packet -- to PDs that normally take their input from the libsigrokdecode I2C PD.
This involves:
- libsigrok would need a facility to send decoded packets over the session bus. This is certainly a new packet type, for example SR_DF_I2C.
- libsigrokdecode would need a way to receive more than just raw logic. The inter-PD Python object format for (in this case) I2C would need to be nailed down and formalized, and a way for the library to receive I2C in packet format and convert to the Python object.
Other scopes that can send decoded data over SCPI
Keysight InfiniiVision 3000 X-Series Oscilloscopes and Agilent InfiniiVision 7000A Series Oscilloscopes:
:LISTer:DATA Query Syntax :LISTer:DATA? The :LISTer:DATA? query returns the lister data. Return Format <binary block><NL> <binary_block> ::= comma-separated data with newlines at the end of each row
RS232
- One or two serial ports could be used as a "poor man's capture device" to decode RS232. The communication parameters for RS232 would have to be known to capture, the higher level protocol could then be analyzed with lsrd.
- The output of a program like interceptty could be converted into the sigrok format and then be analyzed. No need to hook up any probes.
Both use cases could be useful if no "real" logic analyzer is available or for debugging.