1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 <2007> 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Using Asyn driver or modifying devLib (or related programs) of EPICS base for any knid of cPCI cards |
From: | Jenny Chen <[email protected]> |
To: | [email protected] |
Date: | Wed, 03 Oct 2007 14:01:40 +0800 |
Dear Sir, We will
use EPICS for our new ring TPS in
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 > 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----- Hi 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----- 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----- Ø
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: 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 Best regards, |