+/*
+ * This sigrok driver implementation uses the vendor's CLI application
+ * for the ASIX OMEGA to operate the device in real time mode. The
+ * external process handles the device detection, USB communication
+ * (FTDI FIFO), FPGA netlist download, and device control. The process'
+ * stdout provides a continuous RLE compressed stream of 16bit samples
+ * taken at 200MHz.
+ *
+ * Known limitations: The samplerate is fixed. Hardware triggers are not
+ * available in this mode. The start of the acquisition takes a few
+ * seconds, but the device's native protocol is unknown and its firmware
+ * is unavailable, so that a native sigrok driver is in some distant
+ * future. Users need to initiate the acquisition in sigrok early so
+ * that the device is capturing when the event of interest happens.
+ *
+ * The vendor application's executable either must be named omegartmcli
+ * and must be found in PATH, or the OMEGARTMCLI environment variable
+ * must contain its location. A scan option could be used when a
+ * suitable SR_CONF key gets identified which communicates executable
+ * locations.
+ *
+ * When multiple devices are connected, then a conn=sn=... specification
+ * can select one of the devices. The serial number should contain six
+ * or eight hex digits (this follows the vendor's approach for the CLI
+ * application).
+ */
+
+/*
+ * Implementor's notes. Examples of program output which gets parsed by
+ * this sigrok driver.
+ *
+ * $ ./omegartmcli.exe -version
+ * omegartmcli.exe Omega Real-Time Mode
+ * Version 2016-12-14
+ * Copyright (c) 1991-2016 ASIX s.r.o.
+ * Email: support@asix.net
+ *
+ * $ ./omegartmcli.exe -bin [-serial SERNO] <NULL>
+ * (five command line words including the terminator)
+ *
+ * The RTM CLI application terminates when its stdin closes, or when
+ * CTRL-C is pressed. The former is more portable across platforms. The
+ * stderr output should get ignored, it's rather noisy here under wine,
+ * communicates non-fatal diagnostics, and may communicate "progress"
+ * which we don't care about.
+ *
+ * Ideally the external process could get started earlier, and gets
+ * re-used across several sigrok acquisition activities. Unfortunately
+ * the driver's open/close actions lack a sigrok session, and cannot
+ * register the receive callback (or needs to duplicate common support
+ * code). When such an approach gets implemented, the external process'
+ * output must get drained even outside of sigrok acquisition phases,
+ * the cost of which is yet to get determined (depends on the input
+ * signals, may be expensive).
+ *
+ * The binary data format is used to reduce the amount of inter process
+ * communication. The format is rather simple: Three 16bit items (LE
+ * format) carry a timestamp (10ns resolution), and two 16bit samples
+ * (taken at 5ns intervals). The timestamp may translate to a repetition
+ * of the last sample a given number of times (RLE compression of idle
+ * phases where inputs don't change). The first timestamp after program
+ * startup is to get ignored. Chunks are sent after at most 32Ki 10ns
+ * ticks, to not overflow the 16bit counter. Which translates to a data
+ * volume of 6 bytes each 328us for idle inputs, higher for changing
+ * input signals.
+ *
+ * Is it useful to implement a set of samplerates in the sigrok driver,
+ * and downsample the data which is provided by the Asix application?
+ * This would not avoid the pressure of receiving the acquisition
+ * process' output, but may result in reduced cost on the sigrok side
+ * when users want to inspect slow signals, or export to "expensive"
+ * file formats.
+ *
+ * This driver implementation may benefit from software trigger support.
+ */
+