|
Dalibor Frivaldsky
02/21/2008 6:36 AM
post5176
|
Hello,
We've an application and a driver. The driver is responsible for real-time communication with a field device. The
communication is done in cycles, 1 ms being the duration of one. During the cycle, there is one smaller period,
announced be the driver by writing STARTOP to a /dev/fcontrol device. We also have a library, that provides an API and
basic functionality needed for communication with the driver. Now, an application registers a callback in this library,
which is called every time the STARTOP is read from the device file by the library. When the application callback
finishes, the library writes OPDONE to the same device. The OPDONE has to be written in 250 us or less. If not, OPFAIL
is generated and the cycle time was wasted for nothing. Now the problem is, that if interrupt comes during the 250 us
period, the application thread does not make the OPDONE write in time. We have tried to encapsulate the application
callback call with DisableInterrupts() and EnableInterrupts(), but the problem prevailed. We have read, that any kernel
call re-enables the interrupts. As we don't have a control of what the application might do when it receives STARTOP, it
is very probable that a kernel call will occur. How can we make sure, that the the application callback will not be
blocked by any interrupt?
Thank you very much
Dalibor
PS: I've attached an architecture diagram
|
|
|
|
|
|
Attilla Danko(deleted)
02/21/2008 10:26 AM
post5184
|
>Now the problem
> is, that if interrupt comes during the 250 us period, the application
> thread does not make the OPDONE write in time.
I'm surprised that an interrupt will do that.
I conjecture its not the interupt handler itself thats causing the delay.
Any chance that handler for the interposing interrupt is readying a high
priority thread to run? If that happens it could certainly delay your
application from getting to OTDONE on time.
A way to tell for sure is to capture a trace of your scenario in the system
profiler.
If you do find that your application is being prempted by a higher priority
thread, then the solution may be to run your application at a higher
priority. You might also consider using the SCHED_FIFO scheduling policy.
Disabling interrupts in application code is pretty nasty, I'd look for other
alternatives first.
-ad
Dalibor Frivaldsky wrote:
> Hello,
>
> We've an application and a driver. The driver is responsible for
> real-time communication with a field device. The communication is done
> in cycles, 1 ms being the duration of one. During the cycle, there is
> one smaller period, announced be the driver by writing STARTOP to a
> /dev/fcontrol device. We also have a library, that provides an API and
> basic functionality needed for communication with the driver. Now, an
> application registers a callback in this library, which is called every
> time the STARTOP is read from the device file by the library. When the
> application callback finishes, the library writes OPDONE to the same
> device. The OPDONE has to be written in 250 us or less. If not, OPFAIL
> is generated and the cycle time was wasted for nothing. Now the problem
> is, that if interrupt comes during the 250 us period, the application
> thread does not make the OPDONE write in time. We have tried to
> encapsulate the application callback call with DisableInterrupts() and
> EnableInterrupts!
>
> (), but the problem prevailed. We have read, that any kernel call
> re-enables the interrupts. As we don't have a control of what the
> application might do when it receives STARTOP, it is very probable that
> a kernel call will occur. How can we make sure, that the the application
> callback will not be blocked by any interrupt?
>
> Thank you very much
>
> Dalibor
>
> PS: I've attached an architecture diagram
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post5176
>
|
|
|
|
|
|
Dalibor Frivaldsky
02/21/2008 12:42 PM
post5189
|
It's not just one interrupt. The application runs ok when the rest of the system is idle. But when mouse is moved, for
example, it's delayed enough not to send OPDONE. We've already tried to run the application with maximum priority, which
did not help it much.
We also tried FIFO scheduling, also with max priority. It helped it just a bit, not really noticeable.
We are aware that interrupt handlers themselves take very little time to execute, though it seems to be enough for the
250 us threshold to be passed.
Thanks
Dalibor
|
|
|
|
|
|
Colin Burgess(deleted)
02/21/2008 1:42 PM
post5191
|
It this a USB mouse? If you have USB Legacy enabled, then the BIOS will be killing
you emulating a PS2 mouse in System Management Mode.
Dalibor Frivaldsky wrote:
> It's not just one interrupt. The application runs ok when the rest of
> the system is idle. But when mouse is moved, for example, it's delayed
> enough not to send OPDONE. We've already tried to run the application
> with maximum priority, which did not help it much.
>
> We also tried FIFO scheduling, also with max priority. It helped it just
> a bit, not really noticeable.
>
> We are aware that interrupt handlers themselves take very little time to
> execute, though it seems to be enough for the 250 us threshold to be passed.
>
> Thanks
>
> Dalibor
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post5189
>
--
cburgess@qnx.com
|
|
|
|
|
|
Dalibor Frivaldsky
02/26/2008 6:55 AM
post5260
|
mouse is not the only device that causes it, it's just the example of one.
We were thinking about it a bit and came to a conclusion, that the problem, as you pointed out, might not be the
interrupts, but their associated driver threads. To make it clear, the 250 us period is counted since our driver thread
writes STARTOP into the device file and then blocks reading the same dev file. The lib/app thread is now unblocked since
there are data to be read from the device. It does what it has to, writes OPDONE to the dev, then blocks while waiting
for another STARTOP. The driver thread now has data to be read from the dev file, so unblocks, reads OPDONE and the
whole cycle goes on. This is has to be done within the 250 us threshold.
Now, we think the problem might be between the reads and writes, since e.g. mouse driver thread might be scheduled,
putting itself between the execution of our driver thread and the lib thread, slowing the whole process down. Our driver
is a port from a linux rt driver, that's why it uses device file for communication. Is it possible that the problem
could be solved using native QNX IPC instead of the dev file?
Dalibor
|
|
|
|
|
|
Thomas Fletcher
02/26/2008 9:02 AM
post5261
|
On Tue, Feb 26, 2008 at 6:55 AM, Dalibor Frivaldsky <
dalibor.frivaldsky@siemens.com> wrote:
> mouse is not the only device that causes it, it's just the example of one.
>
> We were thinking about it a bit and came to a conclusion, that the
> problem, as you pointed out, might not be the interrupts, but their
> associated driver threads. To make it clear, the 250 us period is counted
> since our driver thread writes STARTOP into the device file and then blocks
> reading the same dev file. The lib/app thread is now unblocked since there
> are data to be read from the device. It does what it has to, writes OPDONE
> to the dev, then blocks while waiting for another STARTOP. The driver thread
> now has data to be read from the dev file, so unblocks, reads OPDONE and the
> whole cycle goes on. This is has to be done within the 250 us threshold.
>
> Now, we think the problem might be between the reads and writes, since e.g.
> mouse driver thread might be scheduled, putting itself between the execution
> of our driver thread and the lib thread, slowing the whole process down. Our
> driver is a port from a linux rt driver, that's why it uses device file for
> communication. Is it possible that the problem could be solved using native
> QNX IPC instead of the dev file?
>
Take a system profiler trace (using tracelogger or the IDE) and you'll see
exactly what is happening with the scheduling.
Operating in with 250us period is very realistic and should be achievable.
Thomas
|
|
|
|
|
|
