Experimental Physics and
Industrial Control System

---

From: [email protected] [mailto:[email protected]] On Behalf Of Jenny Chen
Sent: Wednesday, October 03, 2007 1:02 AM
To: [email protected]
Subject: Using Asyn driver or modifying devLib (or related programs) of EPICSbase for any knid of cPCI cards

Dear Sir,

  We will use EPICS for our new ring TPS in Taiwan, we might choose cPCI bus running Linux OS on IOC to reduce the budget (cheaper in Taiwan). My question is: is it possible to access cPCI cards as VME cards (memory mapping and register access) in EPICS? Or it is easier to do that by using AsynDriver. I got some suggestions from seniors, I appreciate them. We are new in EPICS, it is good to have more suggestions before we take any action. Thanks!

From: Eric Norum [mailto:[email protected]]
Sent: Tuesday, October 02, 2007 8:02 PM
 Subject: Re: about porting EPICS

 

I am not quite sure what you are asking so I will provide three answers:

1) As much as possible, you should avoid creating new record types.

2) The ASYN 'devEpics' layer isolates the driver code from the record 

type.  This can be very useful since the same driver can be used with 

an mbbi, mbbiDirect, bi, or longin record, for example.

3) You do not have to provide support for every possible record type.

 

On Oct 1, 2007, at 9:30 PM, Jenny Chen wrote:

> Dear Sir,

>

>   Thanks very much for your help. Now I understand a little more

> about the complexity of using all possible cards that are cPCI bus 

> standard on the IOC running Linux OS. I know a little about the 

> cPCI access, the address of the cards cannot be defined before the 

> driver installed, it is dynamic. As Dr. Johnson mentioned, if the 

> venders support the driver we may simply call read/write/open/close/

> ioctl to access the cards by using Asyn driver to build the IOC. 

> Then I got another question, if we don’t change anything in the 

> EPICS base, it means that we should implement all database record 

> type, ai/ao/di/do/mbbi/mbbo/mbbiDirect/mbboDirect/event/longin/

> longout/pulseCounter/pulseDelay/pulseTrain/waveform, any record 

> type related to hardware (anything we need), right?

 

-----Original Message-----
From: Andrew Johnson [mailto:[email protected]]
Sent: Tuesday, October 02, 2007 2:10 AM
To: Eric Norum
Cc: Jenny Chen; Jeff Hill; Till Straumann; Mark Rivers; Marty Kraimer
Subject: Re: about porting EPICS

 

Hi Jenny,

To touch on a question that the others have not mentioned yet: If you

can find cPCI I/O cards for which a Linux device driver is already

available (in some cases there may even be a user library provided by

the manufacturer too), then the task of controlling them from EPICS

should be very much simpler and should not involve making any changes to

EPICS Base at all.  In this circumstance I would definitely recommend

using Asyn for your interface layer since Linux drivers may block the

calling thread; you would write an Asyn port driver to call the user I/O

library or do the necessary open/close/read/write calls, and Asyn would

create a separate port thread which would be used to make those calls.

 

You might find that (if you can get them) it is worth paying more money

for cPCI cards that have a Linux device driver from the manufacturer

than writing your own for cards that don't.

 

- Andrew Johnson

--

 

-----Original Message-----
From: Eric Norum [mailto:[email protected]]
Sent: Tuesday, October 02, 2007 1:20 AM
To: Jenny Chen; Jeff Hill
Cc: Till Straumann; Mark Rivers; Marty Kraimer; Andrew Johnson
Subject: Re: about porting EPICS

 

The biggest issues to deal with when moving hardware support to Linux 

are those raised by the kernel/user boundary.  Devices not requiring 

interrupts are easily handled by mapping the I/O registers and/or 

memory to user space.  This is how I dealt with the digital and 

analog I/O ports on the 'EPICS brick' (PC-104 card with Linux) some 

time ago.  Devices requiring interrupt support (or even more complex, 

those requiring Bus Master transactions) are more of a problem.   You 

can move the entire driver to kernel space and then use read/write/

ioctl system calls to access the driver from the IOC code or you can 

handle the interrupt in kernel space and forward the request to the 

user-space driver.  I strongly recommend against using POSIX signals 

for this purpose.  A better approach is to have an 'interrupt 

handler' thread in user space that is blocked in a 'read' system call 

until the interrupt occurs.

 

 

-----Original Message-----
From: Jeff Hill [mailto:[email protected]]
Sent: Tuesday, October 02, 2007 12:57 AM
To: 'Jenny Chen'
Cc: [email protected]; 'Eric Norum'; Mark Rivers; Marty Kraimer; Andrew Johnson
Subject: RE: about porting EPICS

 

Ø      My question is: aren’t they accessed by the IOC is just as VME cards (I mean register access)?

I agree that the register access model might make some of the cPCI drivers quite similar to vme drivers. However, I am also aware that the asyn driver advocates are pushing for register based devices to be interfaced with the async driver (an expansion of its original domain). I don’t claim to fully understand all of the reasons for and against such an approach, but I can say that some experienced programmers are among those in favor.

 

Ø      When I look at the src/libCom/osi/devLib.c devLib.h I found some functions are related to

Ø      bus access and interrupt handler. Don’t we have to add something into or modify them?

Ø      Because I just have a little experience about EPICS IOC development, I don’t know

Ø      how many programs are related to the bus access (cPCI address mapping, install

Ø      interrupt handler,…).

 

It does appear to be appropriate to extend the devLib interface to include also cPCI. Perhaps this might be a way to get started.

 

1)     Check on tech-talk mail list to see if other sites are working with cPCI with the hope that someone else may have already done the work J. If there is work in progress, it may still be necessary to extend  it or to repackage it for use with devLib.

2)     If you are the first cPCI site, then perhaps you could look at the online documentation for Linux, vxWorks, and RTEMS to provide some insight when designing an appropriate interface for mapping the cPCI addresses.

3)     Once you have a design for the new interface then publish it (perhaps only your modified devLib.h header file) for review on tech-talk.

4)     Attempt to look at all  of the comments, being fully aware that you can try to accommodate everyone’s requests but some compromises are always necessary, and arrive at a final design.

 

I, and the others cc’d on this message, will be happy to answer any further questions that you might have.

Jeff

 

From: Jenny Chen [mailto:[email protected]]
Sent: Friday, September 28, 2007 2:50 AM
To: 'Jeff Hill'
Subject: RE: about porting EPICS

 

Dear Dr. Hill,

  Thanks very much for your help about how we can elevate our capability of EPICS. Three of us had attended to USPAS EPICS course once. It helped a lot. We also had CosyLab’s help to build EPICS on a microIOC and a linux host to drive an Enet base motion controller to drive a prototype APU.  It bases on async driver.

  For our new ring, we may choose cPCI instead of VME bus. We may purchase cPCI DI/DO/AI/AO cards, they are cheaper in Taiwan. My question is: aren’t they accessed by the IOC is just as VME cards (I mean register access)? When I look at the src/libCom/osi/devLib.c devLib.h I found some functions are related to bus access and interrupt handler. Don’t we have to add something into or modify them? Because I just have a little experience about EPICS IOC development, I don’t know how many programs are related to the bus access (cPCI address mapping, install interrupt handler,…). Before we ask for CosyLab’s help, I think we have to know some about it. Would you please teach me some about it? Thanks very much!

Best regards,

Jenny.