TODO

libsigrok

• • 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).
• all output modules should use GString API instead of estimating output size
• VCD input modules
• OLS format input module
• 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).
• 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.

New features

• Support for analog devices, starting with oscilloscopes.
• Finish fx2lafw (open-source FX2 firmware).
• 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.
  • Factor out input/output file formats to libsigrokfile.

Windows port

• Implement anykey.c replacement.
• 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.

Hardware support

• Hantek DSO-2090 driver
• ANT8/18e unified driver
• udev:
  • Make udev optional, only build MSO driver if it's available
  • have OLS driver use udev if available, fall back to serial port probing otherwise
  • Find alternative to udev for windows and macos
• Clean up device-specific globals in hardware drivers, to properly permit multiple devices per driver: asix-sigma, demo (not relevant), link-mso19, openbench-logic-sniffer, saleae-logic, zeroplus-logic-cube

Miscellaneous

• 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.
• There may be issue if none of the drivers is enabled, print useful error in that case(?)

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.

Old

• 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

• ...

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.
• 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)
• Linux distro packages for non-Debian distros.
• FreeBSD packages/ports.

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
• Make sure all optional components are really optional in the build system:
  • Only require Python if the users wants protocol decoders, the rest should also build/compile/run fine without Python installed.
• Python bindings for libsigrok and libsigrokdecode.