Experimental Physics and
Industrial Control System

"Szalata, Zenon M." <[email protected]> · Sun, 1 May 2011 21:32:19 -0700

Thank you Andrew, Eric and Till,

My thinking was to upgrade the existing IOCs and support modules needed by those IOCS with minimum necessary modifications to avoid altering functionality.  Part of the problem is that the IOCs use extensive and complicated sets of EPICS records, custom record types for which support is built into the device drivers (support modules) and I am not very familiar with the inner workings of all that.
So, I was thinking to do the transition in two steps; first to just get the software upgraded and moved from the solaris platforms where the software is presently maintained, the second would be to take one system at a time and re-implement all device drivers to be OSI as needed, perhaps using asynPortDriver...
I realize that once the first step is completed successfully, the second step may never be taken.
Zen

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Sunday, May 01, 2011 8:33 PM
> To: [email protected]
> Cc: Szalata, Zenon M.; Straumann, Till
> Subject: Re: EPICS task watch dog
> 
> Hi Zen,
> 
> On Sunday, May 01, 2011 21:38:53 Szalata, Zenon M. wrote:
> > Till, Thank you for your input.
> > I understand your suggestion.
> > There is another related issue, which I am not sure about.
> > In the existing driver code, the task is created with a call to vxWorks
> > routine taskSpawn(...).  Here is a code fragment:
> 
> Actually if you follow Till's suggestion properly you would replace *all* the
> calls to vxWorks-specific routines in the driver with their EPICS equivalents.
> Instead of taskSpawn() you use epicsThreadCreate(), etc.  This has the
> advantage that the resulting code can be compiled for and will run on RTEMS,
> but it is a bit more work since the EPICS versions are not all direct
> replacements for their vxWorks counterparts.  Eric Norum produced a Wiki
> page
> describing the conversions of the various routines, which you can read at this
> link:
> http://www.aps.anl.gov/epics/wiki/index.php/How_to_make_your_EPICS_driv
> er_operating_system_independent
> 
> If you don't want to put that much effort into this, on vxWorks you can just
> cast an epicsThreadId into an integer for use as a task-id in vxWorks routines
> and vice-versa.  That is not possible on other operating systems though.
> 
> HTH,
> 
> - Andrew (waiting for Obama's special news conference to start)

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System