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 fsmRecord question |
From: | Michael Davidsaver <[email protected]> |
To: | Jiro Fujita <[email protected]> |
Cc: | Michael Cherney <[email protected]>, [email protected], EPICS tech-talk <[email protected]> |
Date: | Mon, 15 Jul 2013 10:28:49 -0400 |
On 07/13/2013 01:06 AM, Jiro Fujita
wrote:
I developed fsmRecord against 3.14.10 and it should build against newer versions. Also, it isn't doing anything special, the only part of OSI it uses is epicsMutex, so it will likely build against earlier 3.14 releases.
And I didn't think to ask...
I wouldn't dream of discourage you from upgrading :) However, I suspect it would be less work to port fsmRecord back. If you were considering this you might have a look at StreamDevice which supports 3.13 (specifically the file StreamEpics.cc). It might be as simple as replacing use of epicsMutex with a vxWorks semaphore.
This is possible, but some care is needed. fsmRecord uses the normal db linking calls, so puts to output CA links queue a request and return immediately. So the FSM might have to include extra states to check (and wait) until this has happened. Michael |