EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  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  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: RTLinux for an IOC
From: "Williams Jr, Ernest L." <[email protected]>
To: Marty Kraimer <[email protected]>, [email protected]
Cc: [email protected]
Date: Tue, 18 Nov 2003 08:09:49 -0500

-----Original Message-----
From: Marty Kraimer [mailto:[email protected]] 
Sent: Tuesday, November 18, 2003 7:58 AM
To: [email protected]
Cc: [email protected]
Subject: Re: RTLinux for an IOC

[email protected] wrote:
> G'day,
> 
> There is a great work going on with RTEMS and, of course Tornado
(vxWorks)
> is the traditional IOC, but is anyone using a semi-commercial variant
of RT
> Linux as a serious IOC? For example I'm looking at RedHawk Linux
> (Concurrent computers -
> http://www.ccur.com/isd_solutions_redhawklinux.asp).
> 
> Any fundamental reason why this might not be a good idea before I try
it?
> Any experiences or thoughts ?


As I recall RTLinux is a small real-time kernel that also runs the
regular Linux 
kernel as a  low priority RTLinux thread. Since an integral part of
EPICS is 
Channel Access it is hard to see how an IOC could be run using only
RTLinux threads.


Once the 2.6 kernel is available, linux will have much better real time 
characteristics. My guess is that, with more work needed on 
base/src/libCom/osi/(posix and/or linux), linux will be sufficient for
most 
EPICS IOC applications.

I have already started playing with the 2.6 kernel but only on the x86
host/target.  A stable test Release of the 2.6 kernel is available for
Red Hat: http://people.redhat.com/arjanv/2.5






For applications with harder real time requirements at least two other 
approaches are available. Both require that the real time requirements
are 
localized to a small part of the application. If the entire application
has hard 
real-time requirements than perhaps EPICS is the wrong solution.

On method is to use RTLinux or RTAI for the hard real-time and write
EPICS 
device/driver support that communicates with the RTLinux or RTAI
threads.

Another approach is becoming available. I/O boards are becoming
available that 
include easily programmable FPGAs and high performance Digital and
Analog I/O. 
The FPGAs can be programmed to handle the hard real-time and again EPICS

device/driver support can be created to communicate with the FPGA code.

Just my thoughts.

Marty Kraimer



Navigate by Date:
Prev: Re: RTLinux for an IOC Marty Kraimer
Next: sequencer SEGV Benjamin Sailer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: RTLinux for an IOC Marty Kraimer
Next: asynDriver Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·