80 likes | 192 Views
Marty Kraimer, Benjamin Franksen, Pete Owens, Eric Norum, and Dirk Zimoch. Asynchronous Driver Support. Asynchronous Driver Support is a general purpose facility for interfacing device specific code to low level communication drivers. Goal. Why. Example: latest 3.14 version of gpibCore
E N D
Marty Kraimer, Benjamin Franksen, Pete Owens, Eric Norum, and Dirk Zimoch Asynchronous Driver Support
Asynchronous Driver Support is a general purpose facility for interfacing device specific code to low level communication drivers. Goal
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.
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.
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
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.
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.
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.