Writing Device Support Eric Norum November 16, 2004 Getting Started with EPICS Lecture Series.

Slides:



Advertisements
Similar presentations
1 2009: Device Support EPICS Device Support Andy Foster Observatory Sciences Limited.
Advertisements

Kazuro Furukawa, KEK, Jan Developing Device Support EPICS Workshop 2009, RRCAT, India Writing Device Support Kazuro Furukawa for EPICS2009 at RRCAT.
1 1999/Ph 514: Channel Access Concepts EPICS Channel Access Concepts Bob Dalesio LANL.
C Structures and Memory Allocation There is no class in C, but we may still want non- homogenous structures –So, we use the struct construct struct for.
1/1/ / faculty of Electrical Engineering eindhoven university of technology Introduction Part 3: Input/output and co-processors dr.ir. A.C. Verschueren.
FIU Chapter 7: Input/Output Jerome Crooks Panyawat Chiamprasert
1 1999/Ph 514: Device and Driver Support EPICS Device and Driver Support Andrew Johnson APS.
Chapter 7 Protocol Software On A Conventional Processor.
EPICS Class – Device/Driver Support
CSS 372 Lecture 1 Course Overview: CSS 372 Web page Syllabus Lab Ettiquette Lab Report Format Review of CSS 371: Simple Computer Architecture Traps Interrupts.
OS Spring’03 Introduction Operating Systems Spring 2003.
Chapter 7 Interupts DMA Channels Context Switching.
Midterm Tuesday October 23 Covers Chapters 3 through 6 - Buses, Clocks, Timing, Edge Triggering, Level Triggering - Cache Memory Systems - Internal Memory.
Asyn Device/Driver Support
1 Lecture 4: Threads Operating System Fall Contents Overview: Processes & Threads Benefits of Threads Thread State and Operations User Thread.
FINAL MPX DELIVERABLE Due when you schedule your interview and presentation.
Contact Information Office: 225 Neville Hall Office Hours: Monday and Wednesday 12:00-1:00 and by appointment.
CHAPTER 3 TOP LEVEL VIEW OF COMPUTER FUNCTION AND INTERCONNECTION
Recall: Three I/O Methods Synchronous: Wait for I/O operation to complete. Asynchronous: Post I/O request and switch to other work. DMA (Direct Memory.
1-1 NET+OS Software Group Flash API Multiple flash memory bank support New Flash API introduction Detailed Flash API Function presentation Supporting.
1 1999/Ph 514: Record Support EPICS Record Support Marty Kraimer APS.
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
Operating Systems Lecture 7 OS Potpourri Adapted from Operating Systems Lecture Notes, Copyright 1997 Martin C. Rinard. Zhiqing Liu School of Software.
A U.S. Department of Energy Office of Science Laboratory Operated by The University of Chicago Argonne National Laboratory Office of Science U.S. Department.
Introduction to Biometrics Dr. Bhavani Thuraisingham The University of Texas at Dallas Lecture #23 Biometrics Standards - II November 14, 2005.
EPICS record/device/driver Support many slides copied from
DAQ Control GSI, Aug 2005Hans G. Essel CBM - DAQ Control1 MBS monitor (FOPI) (J.Adamczewski, M.Stockmeier)
NT Kernel CS Spring Overview Interrupts and Exceptions: Trap Handler Interrupt Request Levels and IRT DPC’s, and APC’s System Service Dispatching.
Computer Architecture Lecture 2 System Buses. Program Concept Hardwired systems are inflexible General purpose hardware can do different tasks, given.
Operating Systems Lecture November 2015© Copyright Virtual University of Pakistan 2 Agenda for Today Review of previous lecture Hardware (I/O, memory,
Processes CS 6560: Operating Systems Design. 2 Von Neuman Model Both text (program) and data reside in memory Execution cycle Fetch instruction Decode.
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
Operating Systems 1 K. Salah Module 1.2: Fundamental Concepts Interrupts System Calls.
1 CS.217 Operating System By Ajarn..Sutapart Sappajak,METC,MSIT Chapter 2 Computer-System Structures Slide 1 Chapter 2 Computer-System Structures.
1 Computer Systems II Introduction to Processes. 2 First Two Major Computer System Evolution Steps Led to the idea of multiprogramming (multiple concurrent.
Silberschatz, Galvin and Gagne  Applied Operating System Concepts Chapter 2: Computer-System Structures Computer System Architecture and Operation.
How to write a MSGQ Transport (MQT) Overview Nov 29, 2005 Todd Mullanix.
CE Operating Systems Lecture 2 Low level hardware support for operating systems.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Operating Systems Processes and Threads.
New IP Drivers using drvIpac Module Driver:CANopen Carrier Driver:GPFC drvIpac ?? CANopen Tip810 CAN Tip810 mv162GPFCatc40vipc310vipc616 Module driver.
4P13 Week 12 Talking Points Device Drivers 1.Auto-configuration and initialization routines 2.Routines for servicing I/O requests (the top half)
Input/Output Problems Wide variety of peripherals —Delivering different amounts of data —At different speeds —In different formats All slower than CPU.
Processes. Process Concept Process Scheduling Operations on Processes Interprocess Communication Communication in Client-Server Systems.
1 Channel Access Concepts – IHEP EPICS Training – K.F – Aug EPICS Channel Access Concepts Kazuro Furukawa, KEK (Bob Dalesio, LANL)
1 Device Controller I/O units typically consist of A mechanical component: the device itself An electronic component: the device controller or adapter.
Interrupts and Exception Handling. Execution We are quite aware of the Fetch, Execute process of the control unit of the CPU –Fetch and instruction as.
Embedded Real-Time Systems Processing interrupts Lecturer Department University.
1 2003/P571: Device and Driver Support EPICS Device and Driver Support (needs updating to R3.14.1) Andrew Johnson APS.
Introduction to Operating Systems Concepts
Processes and threads.
User-Written Functions
Chapter 7 Text Input/Output Objectives
Java Programming Language
Chapter 7 Text Input/Output Objectives
Module 2: Computer-System Structures
File I/O in C Lecture 7 Narrator: Lecture 7: File I/O in C.
Lecture Topics: 11/1 General Operating System Concepts Processes
Threads Chapter 4.
Operating Systems Lecture 3.
Module 2: Computer-System Structures
EPICS Record/Device/Driver Support Interfaces
Interrupt handling Explain how interrupts are used to obtain processor time and how processing of interrupted jobs may later be resumed, (typical.
Channel Access Concepts
Module 2: Computer-System Structures
Chapter 13: I/O Systems.
Channel Access Concepts
Chapter 3: Process Management
Chapter 13: I/O Systems “The two main jobs of a computer are I/O and [CPU] processing. In many cases, the main job is I/O, and the [CPU] processing is.
Presentation transcript:

Writing Device Support Eric Norum November 16, 2004 Getting Started with EPICS Lecture Series

Writing Device Support – Scope An overview of the concepts associated with writing EPICS Device Support routines. Examples show the “stone knives and bearskins” approach. The ASYN package provides a framework which makes writing device support much easier. –The concepts presented here still apply.

Writing Device Support – Outline What is ‘Device Support’? The.dbd file entry The driver DSET Device addresses Support routines Using interrupts Asynchronous input/output Callbacks

What is ‘Device Support’? Interface between record and hardware A set of routines for record support to call –The record type determines the required set of routines –These routines have full read/write access to any record field Determines synchronous/asynchronous nature of record Performs record I/O –Provides interrupt handling mechanism

Why use device support? Could instead make a different record type for each hardware interface, with fields to allow full control over the provided facilities. A separate device support level provides several advantages: –Users need not learn a new record type for each type of device –Increases modularity I/O hardware changes are less disruptive Device support is simpler than record support Hardware interface code is isolated from record API Custom records are available if really needed. –By which I mean “really, really, really needed!” –Existing record types are sufficient for most applications.

How does a record find its device support? Through.dbd ‘device’ statements:

The.dbd file entry The IOC discovers device support from entries in.dbd files device(recType,addrType,dsetName,”dtypeName”) addrType is one of AB_IOBITBUS_IOCAMAC_IOGPIB_IO INST_IORF_IOVME_IOVXI_IO dsetName is the name of the C Device Support Entry Table (DSET) By convention name indicates record and hardware type: device(ai, GPIB_IO, devAidg535, "dg535") device(bi, VME_IO, devBiXy240, "XYCOM-240")

The DSET A C structure containing pointers to functions Content dependent upon record type Each device support layer defines a DSET with pointers to its own functions A DSET structure declaration looks like: struct dset { long number; long (*report)(int level); long (*initialize)(int pass); long (*initRecord)(struct … *precord); long (*getIoIntInfo)(…); … read/write and other routines as required }; number specifies number of pointers (often 5 or 6) A NULL is given when an optional routine is not implemented DSET structures and functions are usually declared static

The DSET – initialize long initialize(int pass); Initializes the device support layer Optional routine, not always needed Used for one-time startup operations: –Start background tasks –Create shared tables Called twice by iocInit() –pass=0 – Before any record initialization Doesn’t usually access hardware since device address information is not yet known –pass=1 – After all record initialization Can be used as a final startup step. All device address information is now known

The DSET – initRecord long initRecord(struct … *precord); Called by iocInit() once for each record with matching DTYP Optional routine, but usually supplied Routines often –Validate the INP or OUTP field –Verify that addressed hardware is present –Allocate device-specific storage for the record Each record contains a void *dpvt pointer for this purpose –Program device registers –Set record-specific fields needed for conversion to/from engineering units

The DSET – read/write long read(struct … *precord); long write(struct … *precord); Called when record is processed Perform (or initiate) the I/O operation: –Synchronous input Copy value from hardware into precord->rval Return 0 (to indicate success) –Synchronous output Copy value from precord->rval to hardware Return 0 (to indicate success)

The DSET – initRecord – Device Addresses Device support.dbd entry was device(recType,addrType,dset,"name") addrType specifies the type to use for the address link, e.g. device(bo,VME_IO,devBoXy240,"Xycom XY240") sets pbo->out : –pbo->out.type = VME_IO –Device support uses pbo->out.value.vmeio which is a struct vmeio { short card; short signal; char *parm; }; IOC Application Developer’s Guide describes all types

A simple example (vxWorks or RTEMS) #include static long initRecord(struct biRecord *prec){ char *pbyte, dummy; if ((prec->inp.type != VME_IO) || (prec->inp.value.vmeio.signal inp.value.vmeio.signal > 7)) { recGblRecordError(S_dev_badInpType, (void *)prec, "devBiFirst: Bad INP"); return -1; } if (devRegisterAddress("devBiFirst", atVMEA16, prec->inp.value.vmeio.card, 0x1, &pbyte) != 0) { recGblRecordError(S_dev_badCard, (void *)prec, "devBiFirst: Bad VME address"); return -1; } if (devReadProbe(1, pbyte, &dummy) < 0) { recGblRecordError(S_dev_badCard, (void *)prec, "devBiFirst: Nothing there!"); return -1; } prec->dpvt = pbyte; prec->mask = 1 inp.value.vmeio.signal; return 0; }

A simple example (vxWorks or RTEMS) static long read(struct biRecord *prec) { volatile char *pbyte = (volatile char *)prec->dpvt; prec->rval = *pbyte; return 0; } static struct { long number; long (*report)(int); long (*initialize)(int); long (*initRecord)(struct biRecord *); long (*getIoIntInfo)(); long (*read)(struct biRecord *); } devBiFirst = { 5, NULL, NULL, initRecord, NULL, read }; epicsExportAddress(dset,devBiFirst);

The DSET – report long report(int level); Called by dbior shell command Prints information about current state, hardware status, I/O statistics, etc. Amount of output is controlled by the level argument –level=0 – list hardware connected, one device per line –level>0 – provide different type or more detailed information

A simple example – device support.dbd file The.dbd file for the device support routines shown on the preceding pages might be device(bi, VME_IO, devBiFirst, “simpleInput”)

A simple example – application.db file An application.db file using the device support routines shown on the preceding pages might contain record(bi, "$(P):statusBit") { field(DESC, "Simple example binary input") field(DTYP, "simpleInput") field(INP, "#C$(C) S$(S)") }

A simple example – application startup script An application startup script (st.cmd) using the device support routines shown on the preceding pages might contain dbLoadRecords("db/example.db","P=test,C=0x1E0,S=0") which would expand the.db file into record(bi, "test:statusBit") { field(DESC, "Simple example binary input") field(DTYP, "simpleInput") field(INP, "#C0x1E0 S0") }

Useful facilities ANSI C routines (EPICS headers fill in vendor holes) –epicsStdio.h – printf, sscanf, epicsSnprintf –epicsString.h – strcpy, memcpy, epicsStrDup –epicsStdlib.h – getenv, abs, epicsScanDouble OS-independent hardware access (devLib.h) –Bus address  Local address conversion –Interrupt control –Bus probing EPICS routines –epicsEvent.h – process synchronization semaphore –epicsMutex.h – mutual-exclusion semaphore –epicsThread.h – multithreading support –recGbl.h – record error and alarm reporting

Device interrupts vxWorks/RTEMS interrupt handlers can be written in C VME interrupts have two parameters –Interrupt level (1-7, but don’t use level 7 on M68k) – often set with on- board jumpers or DIP switches –Interrupt vector (0-255, <64 reserved on MC680x0) – often set by writing to an on-board register OS initialization takes two calls 1.Connect interrupt handler to vector devConnectInterruptVME(unsigned vectorNumber, void (*pFunction)(void *),void *parameter); 2.Enable interrupt from VME to CPU devEnableInterruptLevelVME (unsigned level);

I/O interrupt record processing Record is processed when hardware interrupt occurs Granularity depends on device support and hardware –Interrupt per-channel vs. interrupt per-card #include to get additional declarations Call scanIoInit once for each interrupt source to initialize a local value: scanIoInit(&ioscanpvt); DSET must provide a getIoIntInfo routine to specify the interrupt source associated with a record – a single interrupt source can be associated with more than one record Interrupt handler calls scanIoRequest with the ‘ioscanpvt’ value for that source – this is one of the very few routines which may be called from an interrupt handler

The DSET – getIoIntInfo long getIoIntInfo(int cmd, struct … *precord, IOSCANPVT *ppvt); Set *ppvt to the value of the IOSCANPVT variable for the interrupt source to be associated with this record You may call scanIoInit to initialize the IOSCANPVT variable if you haven’t done so already Return 0 to indicate success or non-zero to indicate failure – in which case the record SCAN field will be set to Passive Routine is called with –(cmd=0) when record is set to SCAN=I/O Intr –(cmd=1) when record SCAN field is set to any other value

The DSET – specialLinconv long specialLinconv(struct … *precord, int after); Analog input (ai) and output (ao) record DSETs include this sixth routine Called just before (after=0) and just after (after=1) the value of the LINR, EGUL or EGUF fields changes “Before” usually does nothing “After” recalculates ESLO from EGUL/EGUF and the hardware range if LINR is LINEAR. Doesn’t change ESLO if LINR is SLOPE. If record LINR field is Linear ai record processing will compute val as val = ((rval + roff) * aslo + aoff) * eslo + eoff Ao record processing is similar, but in reverse

Asynchronous I/O Device support must not wait for slow I/O Hardware read/write operations which take “a long time” to complete must use asynchronous record processing –T I/O  100  s – definitely “a long time” –T I/O  10  s– definitely “not a long time” –10  s < T I/O < 100  s– ??? If device does not provide a completion interrupt a “worker” thread can be created to perform the I/O –this technique is used for Ethernet-attached devices

Asynchronous I/O – read/write operation Check value of precord->pact and if zero: –Set precord->pact to 1 –Start the I/O operation write hardware or send message to worker thread –Return 0 When operation completes run the following code from a thread (i.e. NOT from an interrupt handler) struct rset *prset = (struct rset *)precord->rset; dbScanLock(precord); (*prset->process)(precord); dbScanUnlock(precord); The record’s process routine will call the device support read/write routine – with precord->pact=1 -Complete the I/O, set rval, etc.

Asynchronous I/O – callbacks An interrupt handler must not call a record’s process routine directly Use the callback system (callback.h) to do this Declare a callback variable CALLBACK myCallback; Issue the following from the interrupt handler callbackRequestProcessCallback(&myCallBack, priorityLow, precord); This queues a request to a callback handler thread which will perform the lock/process/unlock operations shown on the previous page There are three callback handler threads –With priorities Low, Medium and High

Extended device support Device support has been extended to include runtime changes of addresses in IN/OUT fields Beginnings of support for failover See application developer’s guide for details

Asynchronous I/O – ASYN This should be your first consideration for new device support It provides a powerful, flexible framework for writing device support for –Message-based asynchronous devices –Register-based synchronous devices Will be completely described in a subsequent lecture