1 / 8

Asynchronous Driver Support

Asynchronous Driver Support is a versatile facility bridging device-specific code to communication drivers, enabling shared low-level driver functionality for multiple protocols. It aims to streamline low-level driver usage across various device interfaces. Initial support includes GPIB, serial, and VXI11, with potential for network-based protocols.

jeffreya
Download Presentation

Asynchronous Driver Support

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Marty Kraimer, Benjamin Franksen, Pete Owens, Eric Norum, and Dirk Zimoch Asynchronous Driver Support

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

  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.

More Related