"Don't block" and "don't alloc/free" certainly are necessary conditions for a routine to be ISR safe. But as you indicate there are a lot more things to worry about as well. Given the range of architectures and compilers with which EPICS can be used I really think that it's best to stick to routines that are explicitly described as safe. This is especially true given that calling a non-safe routine is likely to result in a system that fails very occasionally in a manner that would be very hard to debug.
Could someone with a more up to date version of the vxWorks manual check and see if there have been additions to the "safe" list since the very old manual from which I quoted?
On Mar 11, 2010, at 8:56 AM, Dirk Zimoch wrote:
> Ron,
>
> To my experience sprintf and sscanf (and also strlen, strcpy and many others) are "ISR save". (Well, they are inherently vulnerable to buffer overflows but that's not limited to interrupts). The basic rule is: don't block. That means in particular don't deal with I/O and don't allocate/free memory. And you just must not use "%f" in the format because you are not allowed to use floating point. Also don't use "long long int" because some compilers use a 64 floating point instruction to copy "long long int" variables.
>
> Dirk
>
> Ron Sluiter wrote:
>> Hi all,
>> Since there is continuing discuss on this topic (on and off
>> tech-talk), I'm posting the complete message Eric sent me
>> at the start of this thread.
>> It sites (chapter and verse) the limits on VxWorks (5.5)
>> facilities from an ISR context. (Is there a comparable
>> version of RTEMS restrictions?)
>> It if ain't approved, I'm not going to risk using it.
>> Ron
>> Eric Norum wrote:
>>> Re: "I have also conditionally added your fix for sprintf() not callable from the RTEMS interrupt context ..."
>>>
>>> I wasn't aware that sprintf() was legal to call from an interrupt context on vxWorks. Or did I misunderstand the change?
>>>
>>>
>>> I found the following in the vxWorks 5.5 manual. First about sprintf():
>>>
>>>
>>> /4.5.1 Special Cases: printf( ), sprintf( ), and sscanf( )/
>>>
>>> The routines *printf( )*, *sprintf( )*, and *sscanf( )* are
>>> generally considered to be part of the standard /stdio/ package.
>>> However, the VxWorks implementation of these routines, while
>>> functionally the same, does not use the /stdio/ package. Instead,
>>> it uses a self-contained, formatted, non-buffered interface to the
>>> I/O system in the library *fioLib*. Note that these routines
>>> provide the functionality specified by
>>> ANSI;* *however, *printf( )* is not buffered.
>>>
>>> Because these routines are implemented in this way, the
>>> full /stdio/ package, which is optional, can be omitted from a
>>> VxWorks configuration without sacrificing their availability.
>>> Applications requiring /printf/-style output that is buffered can
>>> still accomplish this by calling *fprintf( )* explicitly to /stdout/.
>>>
>>>
>>>
>>>
>>> And then about ISRs:
>>>
>>>
>>> /2.6.4 Special Limitations of ISRs/
>>>
>>> Many VxWorks facilities are available to ISRs, but there are some
>>> important limitations. These limitations stem from the fact that
>>> an ISR does not run in a regular task context and has no task
>>> control block, so all ISRs share a single stack.
>>>
>>>
>>> Table 2-21: *Routines that Can Be Called by Interrupt Service
>>> Routines*
>>>
>>> ------------------------------------------------------------------------
>>> *Library*
>>>
>>> *Routines*
>>> ------------------------------------------------------------------------
>>> *bLib*
>>>
>>> All routines
>>> *errnoLib*
>>>
>>> *errnoGet( )*, *errnoSet( )*
>>> *fppArchLib*
>>>
>>> *fppSave( )*, *fppRestore( )*
>>> *intLib*
>>>
>>> *intContext( )*, *intCount( )*, *intVecSet( )*, *intVecGet( )*
>>> *intArchLib*
>>>
>>> *intLock( )*, *intUnlock( )*
>>> *logLib*
>>>
>>> *logMsg( )*
>>> *lstLib*
>>>
>>> All routines except *lstFree( )*
>>> *mathALib*
>>>
>>> All routines, if *fppSave( )*/*fppRestore( )* are used
>>> *msgQLib*
>>>
>>> *msgQSend( )*
>>> *pipeDrv*
>>>
>>> *write( )*
>>> *rngLib*
>>>
>>> All routines except *rngCreate( )* and *rngDelete( )*
>>> *selectLib*
>>>
>>> *selWakeup( )*, *selWakeupAll( )*
>>> *semLib*
>>>
>>> *semGive( )* except mutual-exclusion semaphores, *semFlush( )*
>>> *sigLib*
>>>
>>> *kill( )*
>>> *taskLib*
>>>
>>> *taskSuspend( )*, *taskResume( )*, *taskPrioritySet( )*, *taskPriorityGet( )*, *taskIdVerify( )*, *taskIdDefault( )*, *taskIsReady( )*, *taskIsSuspended( )*, *taskTcb( )*
>>> *tickLib*
>>>
>>> *tickAnnounce( )*, *tickSet( )*, *tickGet( )*
>>> *tyLib*
>>>
>>> *tyIRd( )*, *tyITx( )*
>>> *vxLib*
>>>
>>> *vxTas( )*, *vxMemProbe( )*
>>> *wdLib*
>>>
>>> *wdStart( )*, *wdCancel( )*
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> For this reason, the basic restriction on ISRs is that they must
>>> not invoke routines that might cause the caller to block. For
>>> example, they must not try to take a semaphore, because if the
>>> semaphore is unavailable, the kernel tries to switch the caller to
>>> the pended state. However, ISRs can give semaphores, releasing any
>>> tasks waiting on them.
>>>
>>> Because the memory facilities *malloc( )* and *free( ) *take a
>>> semaphore, they cannot be called by ISRs, and neither can routines
>>> that make calls to *malloc( )* and *free( )*. For example, ISRs
>>> cannot call any creation or deletion routines.
>>>
>>> ISRs also must not perform I/O through VxWorks drivers. Although
>>> there are no inherent restrictions in the I/O system, most device
>>> drivers require a task context because they might block the caller
>>> to wait for the device. An important exception is the VxWorks pipe
>>> driver, which is designed to permit writes by ISRs.
>>>
>>> VxWorks supplies a logging facility, in which a logging task
>>> prints text messages to the system console. This mechanism was
>>> specifically designed for ISR use, and is the most common way to
>>> print messages from ISRs. For more information, see the reference
>>> entry for *logLib*.
>>>
>>> An ISR also must not call routines that use a floating-point
>>> coprocessor. In VxWorks, the interrupt driver code created
>>> by *intConnect( )* does not save and restore floating-point
>>> registers; thus, ISRs must not include floating-point
>>> instructions. If an ISR requires floating-point instructions, it
>>> must explicitly save and restore the registers of the
>>> floating-point coprocessor using routines in*fppArchLib*.
>>>
>>> All VxWorks utility libraries, such as the linked-list and
>>> ring-buffer libraries, can be used by ISRs. As discussed earlier
>>> (/2.2.6 Task Error Status: errno/
>>> <http://slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/guide/c-basic.html#98918>),
>>> the global variable *errno* is saved and restored as a part of the
>>> interrupt enter and exit code generated by
>>> the *intConnect( )* facility. Thus, *errno* can be referenced and
>>> modified by ISRs as in any other code. Table 2-21
>>> <http://slac.stanford.edu/exp/glast/flight/sw/vxdocs/vxworks/guide/c-basic.html#91424> lists
>>> routines that can be called from ISRs.
>>>
>>>
>>>
>>> No mention of either sprintf() or fioLib there.....
>>>
>>>
>>> On Mar 8, 2010, at 1:18 PM, Ron Sluiter wrote:
>>>
>>>> Hello Jens,
>>>>
>>>> The common code for the old device support record
>>>> initialization; "motor_init_record_com()" was not always
>>>> passing positive encoder ratio values. This has been a
>>>> bug for a long, long time that is now fixed.
>>>>
>>>> I have also conditionally added your fix for sprintf()
>>>> not callable from the RTEMS interrupt context to the
>>>> MAXv ISR.
>>>>
>>>> Both of these changes will be available, soon, in the
>>>> next release.
>>>>
>>>> Thanks for pointing out these problems,
>>>> Ron
>>>>
>>>>
>>>> [email protected] <mailto:[email protected]> wrote:
>>>>> Hello Ron,
>>>>>
>>>>>
>>>>>> but the motor record has not issued negative
>>>>>> encoder ratio commands for a long time.
>>>>>>
>>>>> here is an extract of the boot messages with drvMAXvdebug=10, while autosave writes -5.55123456e-06 to the ERES-field.
>>>>>
>>>>> --
>>>>> send_mess: sent card 0 message:'
>>>>> AX ER-180140,52359 UU-3.440496
>>>>> --
>>>>> This command (ER-180140,52359) does not work for
>>>>> current firmware versions.
>>>>>
>>>>>
>>>>>> Are you using a really old
>>>>>> version of the motor record?
>>>>>>
>>>>> No, this is the motorR6-4-4
>>>>> EpicsRelease 3.14.11
>>>>>
>>>>> Jens
>>>>> _______________________________
>>>>> Jens Eden
>>>>> Physikalisch-Technische Bundesanstalt
>>>>> Albert-Einstein-Straße 15
>>>>> 12489 Berlin
>>>>>
>>>>> Tel +49 30 6392-5086
>>>>> Fax +49 30 6392-5082
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Von:
>>>>> Ron Sluiter <[email protected] <mailto:[email protected]>>
>>>>> An:
>>>>> [email protected] <mailto:[email protected]>
>>>>> Kopie:
>>>>> [email protected] <mailto:[email protected]>
>>>>> Datum:
>>>>> 05.03.2010 21:12
>>>>> Betreff:
>>>>> Re: 2 MAXv problems
>>>>>
>>>>>
>>>>>
>>>>> Hello Jens
>>>>>
>>>>> There has been a recent (R6-4 and above) fix to prevent intermittent MAXv command
>>>>> errors from occurring when User Units are turned off, but the motor record has not
>>>>> issued negative encoder ratio commands for a long time. Are you using a really old
>>>>> version of the motor record?
>>>>>
>>>>> Ron
>>>>>
>>>>>
>>>>> [email protected] <mailto:[email protected]> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I found, that in recent firmware versions (1.31) of the MAXv cards the command to set
>>>>>> negative encoder resolutions (e.g. "AX ER-2,3") as used by the MAXv
>>>>> driver
>>>>>> does not work any more.
>>>>>> Instead a command error is returned and the encoder resolution will
>>>>> remain
>>>>>> unchanged.
>>>>>> I couldn't find this "new feature" documented anywhere.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Eric Norum
>>> [email protected] <mailto:[email protected]>
>>>
>>>
>>>
>>>
>
--
Eric Norum
[email protected]
- Replies:
- Re: 2 MAXv problems Steven M. Hartman
- References:
- 2 MAXv problems Jens . Eden
- Re: 2 MAXv problems Ron Sluiter
- Re: 2 MAXv problems Jens . Eden
- Re: 2 MAXv problems Ron Sluiter
- Re: 2 MAXv problems Ron Sluiter
- Re: 2 MAXv problems Dirk Zimoch
- Navigate by Date:
- Prev:
RE: Building StreamDevice 2-4 / SynApps / Win32 Mark Rivers
- Next:
Re: Building StreamDevice 2-4 / SynApps / Win32 John Dobbins
- 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
- Navigate by Thread:
- Prev:
Re: 2 MAXv problems Dirk Zimoch
- Next:
Re: 2 MAXv problems Steven M. Hartman
- 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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·