Experimental Physics and
| |||||||||||||||||
|
Andrew Johnson wrote about mvme6100: Yes; this discussion is about how to actually do that in a way that catches the right task and provides a pointer to the code that failed so that engineers and technicians can track down problems quickly. For those applications, it seems that the overhead for the VME read/write is necessary to be considered only inside the related ISRs or in the related non-ISR routines where the interrupt has to be disabled, which is rare. Actually I don't think it's that rare. I have counted something like 30 calls to the vxWorks intLock() routine in our R3.13.10 support module area, most of which are protecting code that manipulates at least one card register over the VMEbus while the lock is held. In addition I counted 79 calls to intConnect(), and most of those ISRs will be manipulating VME card registers. Every one of those drivers must be examined and may have to be modified if we decide to use a Tempe-based CPU board here. That's a lot of work! The PCIbus Retry and Disconnect cycle terminations that you discussed do not actually stop the data transfer cycle completely, they only permit it to be run again or to take longer to complete than a regular PCIbus single I/O cycle. - Andrew -- There is considerable overlap between the intelligence of the smartest bears and the dumbest tourists -- Yosemite National Park Ranger
| ||||||||||||||||
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |