[PATCH 00/13] device-global identifiers and routes introduced

Ian Abbott abbotti at mev.co.uk
Fri Sep 21 12:40:36 UTC 2018


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 at mev.co.uk> || 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. )=-


More information about the devel mailing list