From: sjk@strl.labs.tek.com (Steven John King)
Newsgroups: comp.os.vxworks
Subject: Re: how to implement a controller
Date: 8 Sep 92 18:42:11 GMT
Reply-To: sjk@strl.labs.tek.com (Steven King)
Followup-To: comp.os.vxworks
Organization: Software Technology Research Lab, Tektronix, Inc.

In article <9209051514.AA08750@thalia.jpl.nasa.gov>, briggs@thalia.jpl.nasa.gov (Clark Briggs) writes:
|> Terry Fong (terry@ptolemy.arc.nasa.gov) summarized his findings about controlling period tasks as:

[Requirements #1 and #2 deleted]

|> 3) HIGH FREQUENCY / LOW LATENCY
|>  
|> If the controller needs to run *really* fast (greater than 10 KHz) or
|> if low latency (jitter) is critical, then as much processing as
|> possible should be done at the interrupt level (since this runs at the
|> highest priority with the lowest latency). One method is to do
|> everything in the ISR. This has problems, however, if other concurrent tasks
|> can't handle interrupts that long. Another approach is to do things
|> similiar to the previous method (i.e., synch a task off of a
|> semaphore), but to try to do some/all of the calcuations in the ISR
|> and to disable the system clock (since the kernel steals 100-300 usecs
|> servicing the clock interrupt).
|> 
|> end of copy of Terry's story...

[Requirements #1 and #2 deleted]
 
|> We have used method 3, too.  The biggest difficulty, beyond the obvious
|> poor behavior of tieing up the cpu, it that the processing done in the
|> ISR really has no context.  this means no file I/O (no surprise, no one
|> would really violate convention that much would they? you bet they would!)and no floating point!
|>  
|> I suggested turning off sysclk, which seems like another
|> terrible thing to do.  It works but can have severe consequences.  This
|> makes sense to me only if the task is soooo important it is necessary
|> to starve everything else, including the network deamons. But, we've
|> been there too.
|>  
|> A final method, is to simply never give up the CPU.  We do this to get
|> 14Khz with 50MHz 68030s.  Make your task highest priority, never sleep,
|> spin on a sync byte (set by the auxclk isr or a companion cpu), turn off
|> sysclk, no file I/O....  This simply dedicates the entire cpu to your
|> task.

Another method, that helps lower both the interrupt latency and context
switch time is to write your own interrupt routine and connect it directly
to the vector, as follows:

1) Copy the wrapper routine generated by intConnect().  If you don't have
   source, simply do an "i" on the routine attached to the clock interrupt.
   You may have to search through the vectors (starting at intVecBaseGet())
   on a running target to find the wrapper code.

2) Remove the calls to intEnt() and intExit().  Instead increment intCnt
   (a global) where intEnt() is called.  Decrement intCnt where intExit()
   is called.

   NOTE: This works for most VxWorks routines that can be called from
         interrupt-level.  NO PROMISE THAT IT WILL ALWAYS WORK.  ;^)

3) If your interrupt handler doesn't receive a parameter, don't push one
   onto the stack.

4) If your "C" routine saves/restores D2, don't save/restore it in this
   routine.  I believe GNU saves it.  Other compilers must not.

5) Perform an RTE at the end of the handler.

6) Connect the handler to the interrupt vector using intVecSet().  Optionally
   save the old on using intVecGet() before the intVecSet().

NOTES:This only saves context switch overhead if the task that will start
      after the interrupt is dismissed is the highest priority task that is
      ready to execute.  In case #3 this will likely be true.  You save the
      lookup overhead in this case.

      In either case you save some of the overhead of the default wrapper
      routine.

      This method is only for the brave, crazy and/or skilled.  Wind River
      probably won't accept support calls if you need help debugging this
      change.

|> Thanks to Terry for the prompt posting and the work to get the information.

Agreed!

-- 
Steven (sjk@strl.labs.tek.com)

"Sometimes if you have a cappuccino and then try again it will work OK."
(Dr. Brian Reid)  "Sometimes one cappuccino isn't enough." (Marcus Ranum)
"A double vanilla latte always works."  (Me)