TODO

libsigrok

Hardware support

• Support for analog devices, starting with oscilloscopes.
• Finish fx2lafw (open-source FX2 firmware).
  • Figure out the problem with this issue and fix it.
• Add a Hantek DSO-2090 driver.
• Tool for firmware extraction of Hantek DSO-2xxx
  • python
  • should parse the .sys files
• Add a Ant8/16/18e unified driver.
• libudev:
  • Make libudev optional, only build MSO driver if it's available.
  • Have OLS driver use libudev if available
  • Find alternative to libudev for Windows and Mac OS X.
• Clean up device-specific globals in hardware drivers, to properly permit multiple devices per driver: asix-sigma, demo, link-mso19, openbench-logic-sniffer, fx2lafw, zeroplus-logic-cube
• ZEROPLUS driver: Fix implementation to work like the other sigrok drivers wrt acquisition/session handling (Uwe Hermann).
• in order to support the CLI --run option, devices will need to provide their buffer size to the frontend, with a DI option.

Input file formats

• Add CSV input format support.
• Add VCD input format support.
• Add OLS input format support.
• Add gnuplot input format support (Uwe Hermann).
• Add Scanalogic input format support (Uwe Hermann).
• Chronovu-LA8 input format: Fix autodetection by checking filesize (Uwe Hermann).

Output file formats

• All output modules should use GString API instead of estimating output size.
• Hex output: Not all lines/columns are of the same length (as they are with real LAs).
• VCD: All samplenumbers are 0 (instead of the proper samplecount).
• OLS, gnuplot: Hangs on MinGW for some reasons (not sure if related).
• CSV: Check if this really works and the syntax is correct. It has various trailing commas, it seems, which should probably be removed.
• Add Scanalogic output format support (Uwe Hermann).
• Add output for latex package tikz-timing.
• Add output for browser waveform viewer/editor written in javascript/JSON called WaveDrom.
• Have a look at DrawTiming http://drawtiming.sourceforge.net (ImageMagick frontend commandline tool).

New features

• Factor out libsigrok filter into modular transform system.
  • take arguments in the regular thing:key=value format
  • integrate current probe compression filter
  • resampling module: sample up/down based on factor argument
  • noise filter: filter out pulses shorter than the samplerate's period
  • software triggering
    • integrate current basic trigger functionality from saleae driver
    • for streaming devices, opportunity for more complex triggers than the hardware can do
    • We will have an extra datafeed type SR_DF_LOGIC_INDEXED, which contains [samplenumber, sample] instead of just raw samples. Samplenumber is a uint64_t, and sample is unchanged (unitsize). Frontends must be able to handle both, and modular filters in libsigrok or the sampling filter in libsigrokdecode may convert from SR_DF_LOGIC to SR_DF_LOGIC_INDEXED at any time.

Windows port

• Implement anykey.c replacement.
• Fix/finish serial port handling code, that's not working, yet.
• Fix/workaround libusb 1.0 Windows port issues:
  • Device renumeration not yet supported (needed for FX2 based LAs).
  • File descriptor / socket based polling not supported in Windows. Workaround (short-term): Use a thread in sigrok.

Miscellaneous

• Use glib functions for file handling, not manual fopen/fclose etc., for portability reasons.
  • Factor out input/output file formats to libsigrokfile.
• All direct uses of file descriptors in the API should disappear, and GIOChannel should be used instead (portability issues).
• Use const for all parameters which are not changed by the API call.
• There must not be any lib-internal data structures that a frontend can manipulate directly. Internal stuff must be non-accessible, except via our defined API calls.
• Mac OS X: B460800 is not available it seems. Find the correct header (if any) and/or find a (possibly platform-specific) workaround, or drop this on Mac OS X.
• Run the code receiving the samples as quickly as possible, run output format code and other non-timing-critical stuff (protocol decoders) in an extra thread. The problem is nicely visible with FX2-based logic analyzers, the longer an output format takes to produce its output, the better your chances to get "oops, I just lost samples" errors.
• Change all code to start counting probes at 0, not 1.
• Get rid of the use of manual polling of FDs, which is not portable (doesn't work on Windows). Use g_poll() instead (which spawns a new thread on Windows).
• sr_errno:
  • Most functions should return SR_OK or SR_ERR_* (same for SRD_OK etc).
  • Most backend functions return status as an integer, which is SR_OK if all went well, or SR_ERR_* and similar if an error occurred.
  • However, there is no way to pass any information back as to what went wrong — and this is important for user-friendliness.
  • Perhaps an error code is not enough; maybe something like sigrok_errno(errorcode, "unsupported device") is better.
• Add good Doxygen documentation for (at least) all public functions.

libsigrokdecode

• Performance: ATM data passed to decode() creates lots of Python objects (-> performance, huge memory usage); find a way to make that more efficient. Use 'bytes' and/or 'memoryview' and the new Python 3 buffer API (?)
• Test/implement config PD method etc.
• Annotations need an additional 'type' field, so that PDs/GUIs can differentiate between different output "things".
  • Types are not yet defined, but could be things like DEFAULT, ERR, WARN, DBG, and others.
  • Best handled with a keyword arg to put(), which defaults to srd.ANN_DEFAULT.
• Processing raw logic vs. everything else up the stack: (optionally) deliver pre-sampled by clock or rate?

  Yes, the controller will deliver a clock- or rate-sampled feed instead, if the PD requests this via a configuration option.

• How to pass (and what exactly, and in which format) samples and already decoded protocol packets:
  • From C to Python (i.e. from libsigrokdecode/controller to the lowest-level decoder)
  • From Python to Python (i.e., from one decoder to the next in the stack)
  • From Python to C (i.e., from a decoder back to libsigrokdecode, which then hands it over to the CLI/GUI, which write it to file or display it in the GUI).
• There will also have to be a type for "sections", i.e. grouped sets of fields that have something in common -- an EDID block, ethernet frame, etc.
  • Actually not needed: these annotations will cover a larger sample range than its individual fields, so it's up to the frontend to do something visually interesting with this.
• Annotations: replace string with optional list, containing annotations in decreasing length?
  • quick and easy form: put(ss, es, opid_ann, "something")
  • multiple strings: put(ss, es, opid_ann, ["something", "else", "yet"])
  • ...or annotations of decreasing length: put(ss, es, opid_ann, ["something", "sth", "s"])
• Test/implement support for multiple outputs of one PD, and stacking different additional PDs on those outputs.
• Test/implement multiple inputs support.
• srd: Python implementation details should be removed from the API.

sigrok-cli

• Stop session if SRD initialization indicates an error at any point.
• Support for printing/selecting a specific annotation for output (or multiple).
• Eliminate all printing to stdout, only sample data or decoder output should end up there. Error/debug messages should go to stderr always.
• enforce input/output options in PDs: don't send logic if PD only accepts i2c etc. figure out what to do with inputs[] and outputs[] (1-wire case)
• Python exception handling in libsrd: add full traceback support with srd_dbg()
• Make specification of triggering capabilities more detailed, so that frontends/GUIs can auto-generate GUI forms out of that metadata.
• Add a --run option, which just starts sampling with the supplied or default samplerate. Contrary to --time or --samples you don't need to explicitly specify a duration or number of samples here, that's automatically determined by the available memory of the logic analyzer and the selected samplerate. Devices that can stream continuously will do so, others will just fill a buffer and then stop.
  • TODO: Similar to --continuous? Merge both?

sigrok-qt

• ...

sigrok-gtk

• File->Open: sigrok-gtk should remember the directory of the last file that was opened/loaded, so that you don't have to browse to the same directory again and again if you load multiple files.
• sigrok-gtk should remember the last window position/size upon shutdown/restart.
• A manpage needs to be written for sigrok-gtk (Uwe Hermann).
• sigrok-gtk needs a time scale (work in progress, haavares on IRC).

Generic items

• sigrok uses uint64_t as an internal datatype to represent a sample, limiting the number of probes on supported hardware to 64. But high-end logic analyzers can have hundreds of probes. A solution would be to switch to either a roll-our-own byte array type, or use GMP. In any case, the overhead of switching over shouldn't be too bad: the filter code and frontend datafeed callback functions will need to use it, but hardware drivers should have enough with a couple of lightweight wrappers.
• Linux distro packages for non-Debian distros.
• FreeBSD packages/ports.
• Python bindings for libsigrok and libsigrokdecode.

Wiki

• Update the relevant wiki API pages with high-level info (details will be in the Doxygen-docs): Protocol Decoder API, Formats and structures, Hardware plugin API, Input API, Output API.
• Make a user-friendly protocol list/lookup page, based on a data-only backend.
• Integrate these into the list: http://en.wikipedia.org/wiki/Category:Serial_buses.

Project

• Protocol decoder repository management:
  • manifest file in every PD directory, containing:
    • list of files to install
    • list of test dumps in sigrok-dumps
    • list of output files to match test dump runs
  • to check before accepting PD into repository:
    • make sure sigrok-dumps has the test files, and the output matches
    • run PD against memory profiler, make sure it doesn't go over X
    • check code coverage againsst test files, make sure it's 100%
    • run against pep8 with custom filter list
  • parse TODO items out of PDs, and present them on the website