Experimental Physics and
Industrial Control System

David Kelly <[email protected]> · Mon, 29 Dec 2003 14:47:53 +1100

Hi,

As I've previously discussed on this mailing list, I'm porting the EPICS IOC
to RedHawk Linux. I want to develop a simple test case to measure the
responsiveness of the RedHawk version, but I need some advice re how to
proceed. My thought was to proceed in either of two ways:

1) Use a second PC to send an interrupt to my system-under-test (SUT), where
the interrupt would be processed through the IOC software and send a
response signal/interrupt back to the originating PC. The originating PC
would measure the response time between its sending of an interrupt signal,
and the reception of a response signal from the SUT.

2) Run the above scenario locally on a single system running the IOC
software. In this case, the interrupt source would be another process
running on the same PC as the IOC software.

My test system contains a Realtime Clock and Interrupt Module (RCIM) board,
which I think is suitable for the above type of testing scenario. It
includes high res timers and 4 incoming edge-triggered interrupt (ETI)
lines. I thought I'd use one of the interrupt lines to watch for an
interrupt and then respond to it. I can generate an interrupt on the chosen
line under software control.

Unfortuneately, the only way (at present) that an application program can be
notified of an interrupt from an RCIM ETI line, is to open an appropriate
device (/dev/rcim/eti0 thru /dev/rcim/eti3) and then issue a special ioctl()
which suspends the process (or thread) until the RCIM ETI line interrupts.
In other words, there is no asynchronous interrupt mechanism (such as
receiving a signal) - the process must use an ioclt() to wait until an
interrupt is received.

Here is where I'd appreciate some assistance and advice. I've read thru the
IOC Application Developer's Guide, and it is not clear to me how to
structure a simple application to implement the above test scenario. For
example:

- I've read the sections about record and device support, and driver
support, but it is unclear to me if/how I can wait for an RCIM ETI line to
interrupt. The processing would have to be asynchronous, which I think means
that I'd have to use a callback, but there is no "interrupt" (as such) from
the RCIM to invoke a callback - some thread would have to be suspended
synchronously behind an appropriate ioclt() call, waiting for the RCIM ETI
line to interrupt. Is there a way to do this ? - from what I can see, all
synchronous processing which takes more than a few tens of microseconds,
must be avoided.... Besides, if I use a synchronous wait ioctl(), I presume
that I will be suspending some thread within the IOC core software - which
is probably a bad thing to do....

- I don't understand how a device support, or driver support, module causes
a callback to fire. To my knowledge, the IOC App Dev Guide chapters on
device and driver support describe how to initiate synchronous and
asynchronous I/O operations, and the various initialisation and
configuration routines - however, I don't understand how a device or driver
module notifies the IOC software of I/O completion, either after a
synchronous I/O operation, or to invoke a callback after an async operation.
(One might even want to "connect" individual device interrupts to IOC
callbacks, but I'm not sure if/how this may be done.)

I'd really appreciate it if someone could set me straight on the above
issues and give me some guidance as how best to structure a simple
response-test application. (If my above test scenario is totally
off-the-planet, please point me in the right direction...) Also, if there's
an existing simple test harness, or device support module, that I could base
my code on, please let me know. (I've looked through the GPIB stuff, but at
this stage I fear it'll take me too long to comprehend it all and then
modify it.)

Thanks for any and all advice...

Regards,

David

P.S. For those that may be interested.... the problem of running "real-time"
processes as root under RedHawk is solved - I can use the Pluggable
Authentication Modules (PAM) to give any login appropriate privileges to
enable true real-time scheduling and memory page locking, etc. Thanks for
the previous discussion around this issue....

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System