home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / vxworks / 792 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  4.1 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!dog.ee.lbl.gov!lbl.gov!vxwexplo
  2. From: briggs@thalia.jpl.nasa.gov (Clark Briggs)
  3. Newsgroups: comp.os.vxworks
  4. Subject: how to implement a controller
  5. Date: Sat, 5 Sep 92 08:14:36 PDT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley CA
  7. Lines: 78
  8. Sender: vxwexplo@lbl.gov
  9. Message-ID: <9209051514.AA08750@thalia.jpl.nasa.gov>
  10. NNTP-Posting-Host: 128.3.112.16
  11. Originator: daemon@vxw.ee.lbl.gov
  12.  
  13. Terry Fong (terry@ptolemy.arc.nasa.gov) summarized his findings about controlling period tasks as:
  14.  
  15. there are three basic approaches:
  16.  
  17. 1) LOW FREQUENCY
  18.  
  19. If the controller runs at less than about 60 Hz, and latency on the
  20. order of a few milliseconds is not a problem, the easiest method is to
  21. run a high priority task that uses taskDelay() to wait between cycles.
  22. The caveats are that taskDelay() runs at system clock granularity and
  23. that the task needs to complete in less than a clock tick (or "time"
  24. will be lost). It is possible to run faster than 60 Hz if you change
  25. the system clock speed (though this will mess up other timing
  26. functions), or if you use an auxiliary clock (if your board has one).
  27.  
  28.  
  29. 2) MEDIUM - HIGH FREQUENCIES
  30. For controllers that run between 30 and 10,000 Hz, a better method
  31. than using taskDelay() is to setup a controller task that synchs on a
  32. binary semaphore. The semaphore is given at the required frequency by
  33. an ISR tied to either the system or auxiliary clock. This is the
  34. recommended method for task synchronization by Wind River Systems, and
  35. is covered in the VxWorks programmer's guide in the synchronization
  36. using semaphores section. Sample code is:
  37.  
  38. code omitted for brevity...
  39.  
  40. 3) HIGH FREQUENCY / LOW LATENCY
  41.  
  42. If the controller needs to run *really* fast (greater than 10 KHz) or
  43. if low latency (jitter) is critical, then as much processing as
  44. possible should be done at the interrupt level (since this runs at the
  45. highest priority with the lowest latency). One method is to do
  46. everything in the ISR. This has problems, however, if other concurrent tasks
  47. can't handle interrupts that long. Another approach is to do things
  48. similiar to the previous method (i.e., synch a task off of a
  49. semaphore), but to try to do some/all of the calcuations in the ISR
  50. and to disable the system clock (since the kernel steals 100-300 usecs
  51. servicing the clock interrupt).
  52.  
  53. end of copy of Terry's story...
  54.  
  55. My Comments:
  56. method 1): changing sysclk from 60hz should not be a problem, in
  57. most respects.  good code can get the sysclk freq and shouldnt code
  58. in 60hz.  I have run sysclk all the way up until the system cant
  59. service the sysclk interrupts fast enough.  This was my first attempt
  60. at running fast controllers.  I got violent frowns from WRS when I
  61. turned sysclk up.  It seems there is nothing inherently wrong with this
  62. its just that they never intended for us to do that to their system.
  63. The most significant problem is this causes the scheduler to run
  64. a lot more and sink a lot of cpu cycles. (In version 4.0 this was
  65. horribly expensive.)
  66.  
  67. Method 2) is the way we run in our labs.  It works well enough, but
  68. is limited by only one sysauxclk.  The isr gets tricky if you are trying
  69. to control several tasks at different rates.
  70.  
  71. We have used method 3, too.  The biggest difficulty, beyond the obvious
  72. poor behavior of tieing up the cpu, it that the processing done in the
  73. ISR really has no context.  this means no file I/O (no surprise, no one
  74. would really violate convention that much would they? you bet they would!)and no floating point!
  75.  
  76. I suggested turning off sysclk, which seems like another
  77. terrible thing to do.  It works but can have severe consequences.  This
  78. makes sense to me only if the task is soooo important it is necessary
  79. to starve everything else, including the network deamons. But, we've
  80. been there too.
  81.  
  82. A final method, is to simply never give up the CPU.  We do this to get
  83. 14Khz with 50MHz 68030s.  Make your task highest priority, never sleep,
  84. spin on a sync byte (set by the auxclk isr or a companion cpu), turn off
  85. sysclk, no file I/O....  This simply dedicates the entire cpu to your
  86. task.
  87.  
  88. Thanks to Terry for the prompt posting and the work to get the information.
  89. Clark Briggs
  90. briggs@csi.jpl.nasa.gov
  91.