Experimental Physics and
Industrial Control System

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 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.

   

 

-- 
Eric Norum
[email protected]