Difference between revisions of "TODO"

From sigrok
Jump to navigation Jump to search
(Updates.)
Line 7: Line 7:
** However, glib solves a number of portability issues for us, so it'll probably stay.
** However, glib solves a number of portability issues for us, so it'll probably stay.
* 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 [http://gmplib.org/ 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.
* 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 [http://gmplib.org/ 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.
== Sigrok 0.1 Stable Release-critical Bugs ==
Sigrok 0.1 comprises only sigrok-cli, i.e. GUI and protocol decoders are not part of the release.
* Ensure that segfaults are rare / non-existing in CLI
* Windows port
* more?


== libsigrok ==
== libsigrok ==

Revision as of 00:04, 13 January 2011

This is a random list of TODO items for the code and/or ideas for improvements.

General

  • Possibly remove the dependency on glib and gthread (various reasons), at least in libsigrok, probably also in sigrok-cli.
    • A new linked list implementation must be found, or written, that duplicates the important parts of glib's GSList (singly-linked list).
    • However, glib solves a number of portability issues for us, so it'll probably stay.
  • 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.

Sigrok 0.1 Stable Release-critical Bugs

Sigrok 0.1 comprises only sigrok-cli, i.e. GUI and protocol decoders are not part of the release.

  • Ensure that segfaults are rare / non-existing in CLI
  • Windows port
  • more?

libsigrok

  • 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.
  • Session loading from file.
  • sigrok_errno:
    • Most backend functions return status as an integer, which is SIGROK_OK if all went well, or SIGROK_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.
    • Both the cmdline and GUI interfaces need this, really, so it should be a backend library thing.
  • configure: Add --enable-hw-foo options to enable/disable support for every device at compile-time. This is useful for different platforms where not all libs are fully supported/available yet (libusb, libftdi, etc), for example.
  • Make sure all optional components are really optional in the build system:
    • Link against libftdi/libusb/etc only if one of the enabled drivers needs those.
    • Only require Python if the users wants protocol decoders, the rest should also build/compile/run fine without Python installed.
    • ...
  • Add output for latex package tikz-timing

libsigrokdecode

  • Keep this independent of libsigrok and any logic analyzer hardware. It should work purely on streams / buffers of bytes to be usable by other projects.

Hardware drivers

  • Bus/driver-independent device instance struct, to replace usb_device_instance and serial_device_instance. Once this is done, device instance-specific information can be cleanly separated and tacked on to the generic device instance:
    • Vendor/model/version scheme in hardware drivers.
    • Clean up device-specific globals in hardware drivers, to properly permit multiple devices per driver.

Template:Fontcolor

Demo driver

It would be good if sigrok would ship with a built-in driver that always works, regardless of hardware connected. This driver would be configurable to provide a clock on a virtual pin, with configurable frequency. It could support multiple of these, at different frequencies.

In addition to giving anyone something to do with sigrok to try it out, this may also have some use cases outside of this: perhaps as a reference clock, next to a live capture.

Since this driver only needs to change to 0/1 at a configurable interval, and the interval is exactly the same as the count of the samples in the datafeed it outputs, the signal it generates would thus be 100% perfect, making it an interesting reference.

Open-source firmware for the FX2 devices

The Cypress FX2-based devices, such as the Saleae Logic and the USBee SX, use only a minimal vendor-provided firmware. The only thing it really does is set the sample rate and turn on the chip's auto-mode. Nevertheless, the vendors provide the firmware as a binary blob, with no source.

It would be great if sigrok could ship with an own firmware implementation for these devices. Some links:

  • SDCC, the Small Devices C Compiler, is a compiler specifically suited to small MCUs, and has support for the 8051 core in the FX2.
  • fx2lib is an open-source library for writing firmware on the FX2. It has a number of interesting functions, including implementing custom USB vendor commands.
  • GNU Radio's USRP2 board has an FX2 on it, and GNU Radio has extensive custom firmware for it.

Uwe Hermann is working on an open-source FX2 firmware for use with various logic analyzers.

sigrok-cli

  • Implement full support for all possible trigger types to be specified via the command-line.

sigrok-gui

  • ...

Decoders

  • Find/evaluate alternatives to psyco for performance improvements on non-x86 architectures.

Windows installer

  • Add support for downloading/installing the Python Windows installer.
  • ...

Code quality and build

  • Consistently use uint64_t for large data types such as samplerate, number of samples, etc.