On Wed, Oct 12, 2016 at 05:05:07AM -0600, Spencer E. Olson wrote: > This patchset introduces a new framework for providing and maintaining a > consistent namespace to define terminal/signal names for a set of comedi > devices. This effort was primarily focused on supporting NI hardware, but the > interfaces introduced here can be implemented by all other hardware drivers, if > desired. Otherwise, these new interfaces do not effect any interfaces > previously defined or prior use cases (i.e. backwards compatibility). > > Some background: > There have been significant confusions over the past many years for users > when trying to understand how to connect to/from signals and terminals on > NI hardware using comedi. The major reason for this is that the actual > register values were exposed and required to be used by end users. Several > major reasons exist why this caused major confusion for users: > > 1) The register values are _NOT_ in user documentation, but rather in > arcane locations, such as a few register programming manuals that are > increasingly hard to find. Some information is found in the register level > programming libraries provided by National Instruments (NI-MHDDK), but > many items are only vaguely found/mentioned in the comments of the NI-MHDDK > example code. There is no one place to find the various valid values of the > registers. > > 2) The register values are _NOT_ completely consistent. There is no way to > gain any sense of intuition of which values, or even enums one should use > for various registers. There was some attempt in prior use of comedi to > name enums such that a user might know which enums should be used for > varying purposes, but the end-user had to gain a knowledge of register > values to correctly wield this approach. > > 3) The names for signals and registers found in the various register level > programming manuals and vendor-provided documentation are _not_ even > close to the same names that are in the end-user documentation. > > 4) The sets of routes that are valid are not consistent from device to device. > One additional major challenge is that this information is not documented > and does not seem to be obtainable in any programmatic fashion, neither > through the proprietary NIDAQmx(-base) c-libraries, nor with register level > programming. In fact, the only consistent source of this information is > through the proprietary NI-MAX software, which currently only runs on > Windows platforms. A further challenge is that this information cannot be > exported from NI-MAX, except by screenshot. > > Similar confusion, albeit less, plagued NI's previous version of their own > proprietary drivers. Earlier than 2003, NI greatly simplified the situation for > users by releasing a new API that abstracted the names of signals/terminals to a > common and intuitive set of names. In addition, this new API provided a much > more common interface to use for most of NI hardware. > > Comedi already provides such a common interface for data-acquisition and control > hardware. This effort complements comedi's abstraction layers by further > abstracting much more of the use cases for NI hardware, but allowing users _and_ > developers to directly refer to NI documentation (user-level, register-level, > and the register-level examples of the NI-MHDDK). > > The goal of these patches are: > 0) Allow current code to function as is, providing backwards compatibility to > the current interface, following a suggestion by Eric Piel. > 1) Provide an interface to connect routes or identify signal sources and > destinations using a consistent naming scheme, global to a driver family. > 2) For NI devices, use terminal/signal naming that is consistent with (a) the > NI's user level documentation, (b) NI's user-level code, (c) the information > as provided by the proprietary NI-MAX software, and (d) the user interface > code provided by the user-land comedilib library. > 3) Make for easy maintenance of register level values that are to be used for > any particular NI device of any particular NI device family. > 4) Provide a means whereby the user can query the set of signal routes that is > valid for a particular device. > 5) Provide an interface whereby the user can query the status and capability > of any signal route. The driver can provide information on whether the > route is valid for the device and whether the route is already connected. > > This patch set implements various changes that keep the goals set forth here. > This patch set is in nowise complete with respect to the various NI hardware > options supported by comedi, though a large selection should be supported--all > e/m-series (ni_mio_common.c hardware) boards and 660x boards are the target of > this patch set, including the tio devices (counter/timers) used by these boards. > > A copy of these patches can be found at: > http://www.umich.edu/~olsonse/patches/comedi-devglobal-v1/ > > Cc: Eric Piel <piel@xxxxxxxxxx> No comment on these patches? At first glance, they look like a good idea to me, but I really don't know the comedi subsystem very well... Ian? thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
