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
-
|
|
|
|
|
|
|
|
|
fppSave( ), fppRestore( )
|
|
intContext( ), intCount( ), intVecSet( ), intVecGet( )
|
|
|
|
|
|
All
routines except lstFree( )
|
|
All
routines, if fppSave( )/ fppRestore( ) are
used
|
|
|
|
|
|
All
routines except rngCreate( ) and rngDelete( )
|
|
selWakeup( ), selWakeupAll( )
|
|
semGive( ) except mutual-exclusion semaphores, semFlush( )
|
|
|
|
taskSuspend( ), taskResume( ), taskPrioritySet( ), taskPriorityGet( ), taskIdVerify( ), taskIdDefault( ), taskIsReady( ), taskIsSuspended( ), taskTcb( )
|
|
tickAnnounce( ), tickSet( ), tickGet( )
|
|
|
|
|
|
|
|
|
-
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 infppArchLib.
-
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), 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 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]
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]>
An:
[email protected]
Kopie:
[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] 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.
|