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.