Design Ideas

From Sigrok

This page contains random design ideas, and should be fleshed out into something a bit closer to later design decisions that were made.

Contents 1 General principles 2 Hardware support 3 Protocol decoders 4 Data Analysis (DA) 5 Platform-independent GUI features 6 Miscellaneous features

General principles

• Use the GNU GPL to ensure all modifications are contributed back to the project etc.
• Use C for speed, optimize data set handling/summarization.
• The libsigrok (backend) library should be completely separate from any frontends, and will do this:
  • Interface with hardware modules via a device plugin system.
  • Data summarization on in-memory buffer and live stream to produce a canvas-sized dataset.
  • Interface with a frontend via a generic API, which every frontend must use.
  • Handle [[Input output formats|input and output formats].
• The libsigrokdecode (protocol decoder) library should be completely separate from any frontends (and from libsigrok), and will provide access to the Python protocol decoders.
• Command line:
  • Should support at least grabbing data from an LA and dump to a file, with cmdline parameters/triggers.
• GUI:
  • Qt GUI: Cross-platform UI via Qt 4 (including support for Linux, Mac OS X, Windows and many other OSes).
  • GTK+ GUI: Based on GTK+ and should be reasonably portable, too.
  • Support for multiple languages / translations of the UI (made easy by Qt).

Hardware support

• Target hardware: See Supported hardware.
• Probe for supported USB hardware on the bus when starting up: vendor/product IDs are easy to find.
  • Use libusb 1.0 for platform-independent USB handling code.
• Should support hotplugged USB devices automagically — is there a platform-independent way to do this?

Protocol decoders

See Protocol decoders.

Data Analysis (DA)

A plugin system that feeds the stream to a DA, and gets either a report or a set of key/value pairs to display. A DA plugin does not necessarily return data that can be displayed alongside the original data stream (though it can do that, too); it usually provides an analysis that works on the whole stream. It should still be fed samples in real time though, and have the possibility of providing live analysis, e.g. for output into a graphing component.

In order to be able to report or graph relevant data, the DA plugin should hint at the type of data it returns. For example it might output clock deviation as a type meaning "an array of numbers between -1 and +1".

Example ideas for DA plugins:

• Analysis of a PWM signal: report duty cycle, deviation from duty cycle, pipe deviation over time into graphing component (PWM catpure).
• Count, analyze, and determine various datapoints, e.g:
  • Input = SPI data. Output = how many pixels were set on the SPI-attached display.
  • Input = Raw signals of (for example) 5 channels. Output: Which of the lines is (likely) TDO, which one is TDI, etc?
  • Input = Raw signals of some channels. Possible outputs:
    • Which protocol is this likely to be (SPI? UART? JTAG? I2C? etc.)
    • Which parameters apply to that protocol?
      • SPI: Rising or falling clock edge?
      • SPI: At which MHz rate does the communication take place?
      • UART: Which Baud rate was used?
      • UART: How many stop bits? Parity?
      • How many (and which) I2C slaves communicated here?
      • LPC/FWH: Which BIOS chip was the host/master talking to (chip vendor ID and device ID)?
  • ...

Example output:

Flags	Key	Value
INTEGER | PERCENTAGE	Duty Cycle	50
INTEGER | ARRAY | DEVIATION	Duty Cycle deviation	[-0.01, 0.02, ...]

Platform-independent GUI features

• Initial interface should be friendly and not complex.
• Lightweight canvas for main analysis display, summarize data according to zoom level.
• Change zoom level with mouse wheel, scrollbar (min=~10 samples on screen, max=all of it for memory display, or 1 second's worth for live stream).
• Keep options open for supporting full oscilloscope streams, not just logic streams. While a full scope needs more options, having a resolution parameter per dataset would already help: 1 bit for LA, e.g. 8 or 16 bits for scope.
• Since some protocol decoders could operate on top of another protocol decoder, this implies a "layer" system. The GUI must provide a way to view/hide specific layers.
• Mode to display the received/sent protocol decoder layers in a hexdump/clean ASCII display, not just the level graph.

Miscellaneous features

• Save session:
  • Configured analyzers, triggers, pin names, UI colors.
  • Hardware used + metadata (port, ...), capture timestamp.
  • Captured data.
  • Need to work out a file format (versioned, extensible!).
• Export any data layer (captured data, different levels of protocol decoders) to raw, CSV, VCD, ODS, and many other formats.