| 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: | Re: EPICS task watch dog |
| From: | Till Straumann <[email protected]> |
| To: | "Szalata, Zenon M." <[email protected]> |
| Cc: | Eric Norum <[email protected]>, "[email protected]" <[email protected]> |
| Date: | Mon, 02 May 2011 09:27:55 -0500 |
On 05/01/2011 11:32 PM, Szalata, Zenon M. wrote:
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
^^^ please note that just 'OSIfying' a driver is a *much* easier task (which can often be done by just using a set of macros or sed scripts) than re-implementing a driver. Can usually be achieved in a few hours. - T. 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)