WinCE60 & CeDriverPerformCallback() in a kernel-mode driver

[Loris]

Hi all,
lately I am facing a problem about the real-time performance of a
WinCE60 system developed around
an OMAP3530 processor with a 500 MHz clock. Everything is compiled for
ARMV4 even if
OMAP3530 is an ARMV7 processor, for which WinCE70 would be required
instead
but, I guess this is not the reason of my problem ...

At present, after some software changes to the system, using the
interrupt of a timer on which
(after leaving the ISR) the kernel signals a named event, I achieved,
on the IST which runs in
a user application (here's the reason of the named event) a jitter of
+/- 150 uSec (that's a
total of 300 microseconds), measured by means of a GPIO toggle and an
oscilloscope.

My goal is to reduce this jitter as mush as possible: +/- 50 uSec
(that's
a total of 100 microseconds) could be enough for my application.

So, I tried to find out what it would happen with the IST handled by a
kernel-mode driver and, just for testing,
I spawned a thread inside the RTC driver, waiting for that named event
and there inside I toggled the usual
GPIO on which I then connected the oscilloscope in order to value its
stability in the same old way. After
that, I measured a total jitter of about 200 uSec, with an improvement
of about 100 uSec compared
to the old situation in which the IST was handled by a user
application.

Then, I moved the GPIO toggle directy inside the timer ISR and from
those 200 uSec, the jitter passed
to a total of 100 uSec: obviously, in this point the scheduler is not
involved yet, right ?

Maybe I am completely wrong but, I would have liked to force a
reschedulation of all threads just after signalling
my named event inside the ISR, in order to reduce as much as possible
the latency between ISR and IST, maybe
calling myself the "SetEvent()" inside the ISR and returning then
"SYSINTR_RESCHED" (instead of my custom
"SYSINTR_*") but, it seems that all of this has been made impossible
in all software levels (OAL and
Installable ISR, to begin with). Maybe, there are some parameters
which can affect (and
possibly boost) the scheduler performance: what do you think ?

I already tried to force the scheduler "Fixed System Tick" mode
(writing
"pOEMUpdateRescheduleTime = NULL" in "OALTimerInit()") but,
without any improvement ...

Last but not least, in order to bypass the latency (possibly)
generated by the scheduler, I was thinking to use
an (hypothetical) call-back to be invoked from within the kernel level
IST (handled for example by the RTC
driver), or even from within the timer ISR when dynamically installed
(Installable ISR), although I know
that ISR is a very critical point and even invoking an empty call-back
there can be heavy but,
at present I am only trying to find a preferential way to execute
something
(the bare essential) with less jitter as possible.

In order to obtain this (just for testing):

1) I opened the RTC driver (which is now for me only a place where to
write some test
code, a pretext in order not to write a new driver yet) from my
user application

2) by means of a "DeviceIOControl()" call I sent some information to
the driver, among
them the call-back handle returned by a
"CeDriverMapCallbackFunction()" call

3) then, inside the "RTC_IOControl()" of the RTC driver, I duplicated
the received
call-back handle by means of a "CeDriverDuplicateCallerHandle()"
call

4) finally, inside the kernel level IST handled by the RTC driver, I
invoked
my call-back by means of the function "CeDriverPerformCallback()"

Well, it seems that all the information are sent to the driver
correctly, the kernel level IST handled by the driver runs.
Even the handle of my call-back isn't null, both the original one
(returned by "CeDriverMapCallbackFunction()")
and its counterpart duplicated inside the driver (returned by
"CeDriverDuplicateCallerHandle()") ... Sad to
say, the "CeDriverPerformCallback()" invoked inside the kernel-mode
driver doesn't execute my
user function and introduces a strange behaviour within the IST
itself ...

Maybe someone else already used this method and can help me to
understand what's wrong.

Thanks in advance for your attention.

Loris.