Difference between revisions of "File format:Protocoldata"

From sigrok
Jump to navigation Jump to search
(start a "protocoldata" input file format page, incomplete)
 
(example file contents and screenshots (to get improved later))
Line 33: Line 33:


== Example file content, example invocations ==
== Example file content, example invocations ==
<gallery>
File:Input-file-protocoldata-uart-screenshot.png
File:Input-file-protocoldata-spi-screenshot.png
File:Input-file-protocoldata-i2c-screenshot.png
</gallery>


[[Category:File format]]
[[Category:File format]]

Revision as of 20:40, 12 July 2023

protocoldata
Name Generate logic traces from protocol's data values
Status supported
Source code (in) protocoldata.c
Source code (out)
Common extension(s) .sr-protocol, .protocol, .bin
MIME type
ASCII format yes

The Protocol data values format can be either binary or text formatted, while the text incarnation is more versatile and useful, easier to read by humans and as easy to generate by external applications. This file format is exclusive to sigrok, its syntax was made up to import UART bytes that were taken from a serial port monitor, then extended to demonstrate its versatility.

The protocoldata input module accepts a sequence of data values as input, optionally interleaved with control instructions, and (re-)creates the waveforms of several logic channels. This makes externally provided data accessible to sigrok decoders even though the capture was not taken by sigrok means and does not come in one of the other supported input formats that sigrok can import.

Several serial protocols are implemented within the input module (currently these are: UART, SPI, and I2C). Adding more protocol handlers is straight forward. The text language is rather expressive and easy to extend, it is assumed that existing infrastructure lends itself well to other protocols that stress different features (controlling select lines, additional ack slots, multiple quanta in a bit slot, phases of differing width, bit stuffing, optional inversion and adjustable signal polarity, etc etc).

Format

TODO Outline binary input, optional magic, optional header, alternative text format. TODO List universally applicable keywords, supported protocols, and protocol specific keywords. TODO Provide example input files, and example invocations.

Overview, alternative input formats

Common keywords, protocol agnostic

UART protocol specific keywords

SPI protocol specific keywords

I2C protocol specific keywords

Example file content, example invocations