On 19/09/18 17:38, Spencer E. Olson wrote:
Because this patchset has come so far after my last version, I am submitting it
without reference to the older patch set.
--
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.
Spencer E. Olson (13):
staging: comedi: tests: add unittest framework for comedi
staging: comedi: add abstracted NI signal/terminal named constants
staging: comedi: add new device-global config interface
staging: comedi: ni_routing: Add NI signal routing info
staging: comedi: add interface to ni routing table information
staging: comedi: ni_mio_common: implement new routing for TRIG_EXT
staging: comedi: ni_mio_common: implement global pfi,rtsi routing
staging: comedi: ni_mio_common: implement output selection of
GPFO_{0,1}
staging: comedi: tio: implement global tio/ctr routing
staging: comedi: ni_mio_common: create device-global access to tio
staging: comedi: ni_660x: Add NI PCI-6608 to list of supported devices
staging: comedi: ni_660x: clean up pfi routing
staging: comedi: ni_660x: add device-global routing
It looks like a lot of effort has gone into this. I've added some
comments in my reply to your PATCH 04/13 regarding additional
constification of the data structures and other minor changes. This
will have knock on effects for the other patches and the maintenance
scripts.
The big thing I think people are going to complain about is the nested
inclusion of .c files (as opposed to linking separately compiled .c
files) so you may need to take another look at that.
I also noticed a lot of the new .c files define static inline functions.
We generally omit the 'inline' and let the compiler decide whether it
is worth inlining them or not (unless the code is especially
time-critical for some reason).
Best regards,
Ian Abbott
--
-=( Ian Abbott <abbotti@xxxxxxxxx> || Web: www.mev.co.uk )=-
-=( MEV Ltd. is a company registered in England & Wales. )=-
-=( Registered number: 02862268. Registered address: )=-
-=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
