Asynchronous Driver Support

1
Asynchronous Driver Support

• Marty Kraimer, Benjamin Franksen,
• Pete Owens, Eric Norum,
• and Dirk Zimoch

2
Goal

• Asynchronous Driver Support is a general purpose
  facility for interfacing device specific code to
  low level communication drivers.

3
Why

• Example latest 3.14 version of gpibCore
• Interfaces supported
• NI1014 - vxWorks only
• VXI11 Ethernet Gpib LAN servers ethernet
  devices that use VXI11
• Serial ports (linux, solaris, vxWorks, LAN serial
  servers, etc)
• Device support is the Winans/Franksen model
• BUT no streams, devAscii, etc.
• DevAscii, onrlSerial, etc.
• Each has own low level driver support but not
  complete.
• Not possible to get all users to switch to one
  devXXX
• Many 10s of thousands of record instances.
• 100s of device support modules.

4
Plan

• Provide a facility that can be used by gpibCore,
  streams, devAscii, devOnrl, mpfSerial, etc.
• Each must be modified so that
• Compatable with existing usage at record/device
  level
• Existing driver support replaced by asynchronous
  driver support
• The benefit is that low level drivers can be
  shared
• Initial support will include
• Gpib
• Serial
• Vxi11 (includes HP gpib lan servers)
• In the future other protocols especially network
  based.

5
Asynchronous Driver Overview

• Asynchronous Driver Components
• asynQueueManager
• Thread for each communication interface
• connectDevice and connectDriver
• queueRequest non blocking can be called by
  scan tasks. The user supplied callback makes
  calls to drivers that may block.
• lock/unlock Provides a transaction service
• register Low level drivers register with the
  asynQueueManager
• asynDriver - Every driver must implement this
  interface
• report
• Connect/disconnect to/from communication
  interface
• octetDriver Most drivers will implement this
  interface
• read/write/flush/setTimeout/setEos/peek

6
Comment

• The above interfaces are sufficient for streams,
  devAscii, devOnrl, mpfSerial, and most gpibCore
  device support.
• Gpib needs additional support for SRQs, EOI,
  universial commands, etc.
• Serial needs additional support for specifying
  baud rate, parity, etc.

7
Gpib Driver Support

• Two layer
• Needed because of SRQs
• GpibDriverUser
• Implements thread for receiving SRQ requests
• Implements SRQ polling
• A gpibDriver registers with gpibDriverUser
• GpibDriverUser registers with asynQueueManager
• GpibDriver
• One for each gpib interface, e.g. NI1014, VXI-11,
  IP488.
• Interface includes asynDriver and octetDriver
  methods. Thus device support that only uses
  read/write requests from gpib supported.

8
Status

• API was refined with input from all Authors
• AsynQueueManager is implemented
• Next step is to port all gpibCore functionality
• Then ready for streams, etc.