Protocol decoders
Jump to navigation
Jump to search
- Plugin system for protocol decoding:
- Should support SPI, I2C, RS232/UART, CAN, USB, JTAG, LPC, FWH, various parallel protocols, and many many more.
- Should be easy to add support for additional/custom protocols, e.g. AT93C46:
- CS (chip select)
- SK (clock)
- DI (data from chip to outside)
- DO (data from outside into chip)
- Has start bit, opcodes, data following transmission
- A protocol as simple as this should be doable to implement without code, only the description of the meaning of the various pins.
- PD plugins must be GUI-independent: they must always work on any GUI present in sigrok. The plugin interface must therefore provide hooks for:
- Providing data from core to plugin - stream or dump.
- Sending analysis results back from the plugin, e.g. timestamps or sample IDs with structured results:
- Type:
- Protocol overhead e.g. start bits
- Commands e.g. opcodes
- Command parameters e.g. address following a READ command
- Extracted data
- String to display over the data ("opcode READ")
- Data (e.g. 10) + length in bits (e.g. 2)
- Results can overlap, as in e.g. "READ address 0x08" and "opcode 10"
- Type:
- This also opens up the possibility of producing e.g. a protocol analysis report from the main code.
- All PD plugins written in Python.
- We embed a scripting language (Python) for very simple transforms and/or additional display; e.g. 4-bit interface to HD44780 LCD, take two nibbles in sequence, based on clock line, and assemble them into a whole byte. Scripted plugin could do this, then pass the data back to the UI for display.
PD plugin infrastructure
The core backend takes a streaming feed from a live aquisition source (or from a saved session). If any PA plugins are configured to act on this source, a pipe is set up to feed this raw data to the embedded Python plugin dispatcher. The dispatcher configures the PD plugins, in order, to write to/read from each other's input and output queues. The dispatcher then starts feeding raw data into the bottom plugin's input queue, and takes output from the top plugin's output queue, which it feeds back to the backend.