m68k Coldfire _ISR_Handler _Thread_Dispatch performance

[Andrew Sinclair]

Hi everyone,

In one Motorola Coldfire (m68k) application, I have encountered a minor
issue with the RTEMS _ISR_Handler routine. 

The problem I have is that a high priority interrupt can perform a
context switch check (_Thread_Dispatch) based on RTEMS system calls made
by a lower priority interrupt. This occurs when the high priority
interrupt has trumped a small critical section in the _ISR_Handler. This
critical section is between just after where the user isr is called in
_ISR_Handler, and just before the call to _Thread_Dispatch. The result
is occasionally the time taken to service the high priority interrupt
can take a little longer even though the high priority interrupt has not
made a RTEMS system call in that instance. If the frequency of the
interrupt is very high, it blocks further interrupts from the same
source occurring, whilst the original interrupt is being serviced. 

The obvious answer is to place the interrupt routine outside RTEMS by
not registering it with an rtems_interrupt_catch, and work out some
other means of communications to tasks. This is the path I am now
taking. 

My argument is that the context switch check should be made at the
interrupt priority level that necessitated the check. I made a patch to
rtems-4.6.2\cpukit\score\cpu\m68k\cpu_asm.S to check this concept, at
least for my application. My application transfers data from a
peripheral, and will only send a RTEMS event when the last character is
received. It seems to work... well at least for the hour I ran it for ;)


I have not included the patch here, as it was very much just a hack, not
very portable, and I also suspect it could influence other RTEMS
features I do not use or that I am aware of. (I suspect that some RTEMS
calls will set flags to initiate a context switch, which is then left to
the timer tick interrupt to perform. Please correct me if I am wrong.)

Does anyone agree with the idea? Is there a better solution? Or... just,
as I am now doing, put that interrupt outside RTEMS scope.

Kind Regards

Andrew Sinclair