Difference between revisions of "TODO"

From sigrok
Jump to navigation Jump to search
(→‎sigrok-cli: Uwe demimoored all over this.)
Line 126: Line 126:
* 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.
* 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?
** TODO: Similar to --continuous? Merge both?
* sigrokdecode probe name matching on level 0 decoders: if the probe names supplied on the cmdline for acquisition or supplied from .sr file match the probes a level 0 PD requires '''exactly''', fill in the probemap accordingly. In all other cases, throw up an error if a level 0 PD has required probes but none were specified as arguments.
* <s>sigrokdecode probe name matching on level 0 decoders: if the probe names supplied on the cmdline for acquisition or supplied from .sr file match the probes a level 0 PD requires '''exactly''', fill in the probemap accordingly. In all other cases, throw up an error if a level 0 PD has required probes but none were specified as arguments.</s>
** (what about optional probes?)


== fx2lafw ==
== fx2lafw ==

Revision as of 07:47, 2 January 2013

The big pre-release TODO

  • SR, SRD: Use const for all parameters which are not changed by the API call.
  • SR, SRD: 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.

libsigrok

Hardware support

  • Support for analog devices, starting with oscilloscopes.
  • Add a Hantek DSO-2090 driver.
  • Add a tool for firmware extraction of Hantek DSO-2xxx.
  • libudev:
    • Make libudev optional, only build MSO driver if it's available. If the user enables the MSO driver, but libudev is not available, politely print an error message and exit.
    • Have OLS driver use libudev if available
    • Find alternative to libudev for Windows and Mac OS X.
      • One idea is to implement a generic USB VID:PID to serial port mapping routine, akin to common/serial. On linux, it would use libudev, while on other OS's this remains to be determined. If for example, libsigrok is build without udev support, then this routine would just return NULL.
  • 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).
    • handle multiple ZP devices properly: currently all devices share the same device context struct
    • move sr_usb_dev_inst to sr_dev_inst, not device context struct. Currently only the last discovered device has the right USB bus/address, all other discovered devices are just lost.
  • Asix SIGMA driver:
    • support multiple devices properly (currently only one is supported).
  • Chronovu-LA8 driver:
    • support multiple devices properly (currently only one is supported).
  • In order to support the CLI --run option, devices will need to provide their buffer size to the frontend, with a DI option.
  • add "mode=sine" parameter to demo driver, to have it output a sine wave in SR_DF_ANALOG floats
  • agilent-dmm:
    • factor out serial_readline2 to common/serial.c version
    • do away with baud rates in profile?
    • time-limited and continuous mode
  • fluke-dmm:
    • time-limited and continuous mode

Input file formats

Output file formats

  • Basic analog text output: display as float, unit suffix?
  • All output modules should use the new output API.
  • All output modules should use GString API instead of estimating output size.
    • binary
    • csv
    • chronovu_la8
    • gnuplot
    • ols
    • text/ascii
    • text/bits
    • text/hex
    • vcd
  • 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).

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).
  • 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.

Before release

  • avoid ABI breakage in the HWCAP enum (done for all enums. Documentation added in HACKING)
    • assign a number to the first of every section/category in the enum, with 10K or so in between assignments.

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

  • Support for printing/selecting one or more specific annotation types for output.
  • 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?
  • sigrokdecode probe name matching on level 0 decoders: if the probe names supplied on the cmdline for acquisition or supplied from .sr file match the probes a level 0 PD requires exactly, fill in the probemap accordingly. In all other cases, throw up an error if a level 0 PD has required probes but none were specified as arguments.

fx2lafw

  • Analog sampling: 1-channel, 2-channel, voltage meter
  • Trigger pin
  • Clock input
  • Clock output
  • Frequency/pulse counter
  • Signal generator

pulseview

  • Add signal naming
  • Add signal arrangement
  • Selection/cursors
  • Threaded sampling
  • Support analog [Very basic support for analog now present]
  • Add save [Working, but held up by changes needed to sigrok-cli and libsigrok]
    • Add progress reporting
  • Make a generative property sheet GUI
  • Make it responsive to SIGABRT etc.
  • Add signal decoding
  • Add signal overview
  • Add triggering
  • Proper error reporting instead of qDebug messages
    • When file-open fails
    • When the LA capture fails
  • Signal groups
  • Paint speed profiling information.
  • Code documentation
  • Transition coding
  • Support different open file formats
  • Migrate to Qt5 and C++11?
  • Tidy up ruler
    • Add some graphical refinements.
    • Stop numbers colliding at high zoom
  • Have some way to configure driver parameters. i.e. serial port for RS-232 devices.
  • Have some way to configure libsigrok* debug level
  • Store config with QSettings

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).

Project

  • Update the relevant wiki API pages with high-level info (details will be in the Doxygen-docs): Protocol decoder API, Formats and structures, Hardware driver API, Input API, Output API.
  • Make a user-friendly protocol list/lookup page, based on a data-only backend.
  • 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
  • FreeBSD packages/ports.

Subprojects

  • Python bindings for libsigrok and libsigrokdecode.

Mugshots

We need better mugshots for the following devices:

  • Acute PKLA-1216 (cropped corner, lens distortion, orange hue)
  • ARMFLY AX-Pro (bottom of the device is cropped out)
  • Braintechnology USB Interface V2.x (orange hue)
  • ChronoVu LA8 (orange hue, severe lens distortion, uneven lighting)
  • ZEROPLUS LAP-16128U (Due to its material, this device needs very careful placement of lights. Avoid reflections and dark shadows - those are nearly impossible to fix)
  • Microchip PICkit2 (Color temperature too low; cannot fix from existing png, uneven lighting)
  • Pico Technology PicoScope 2203
  • Pico Technology PicoScope 2205
  • RDing TEMPer1K2 (none of the angles are usable as a 'pretty' mugshot)
  • Voltcraft DL-120TH (Bottom shadow makes it impossible to correctly identify the edge)
  • Voltcraft DL-140TH
  • Robomotic BugLogic 3 (Poor contrast)
  • MiniLA Mockup (severe lens distortion)
  • QuantAsylum QA100 (Huge bright spot -- probably from the camera flash)
  • Rigol VS5202D (none of the angles are usable as a 'pretty' mugshot)
  • V&A VA18B (mugshot blurry due to excessive perspective and color correction)
  • MASTECH MS6252B (The mugshot we currently have is acceptable. The problem is that the blades are underexposed, and will not look well when the background is cropped. Please make sure there is sufficient light on the fan blades; if they are made from the same plastic as the case, they should display the same brightness. This is a more difficult shot due to the shape of the device; it may take some playing around with the lights.)
  • Agilent MSO7104A (device is tilted and out of focus; applying perspective correction makes the out-of-focus problem evident. Device is also slightly underexposed; looks frightening on a white background)

See Picture Guidelines for more details.