Q\A about VME bus for Vxworks 2
2012-08-14 20:22
197 查看
Aditya Amar wrote: > 1.The VMEbus has 7 levels of prioritized interrupts (IRQ1...IRQ7) . If > I am generating IRQ4 from our custom designed h/w board then what > should be the argument in the call to sysIntEnable from within vmeMain IRQ4 => sysIntEnable(4) > When I generated an IRQ4 interrupt from our custom board , over the > VMEbus and called sysIntEnable(4) to enable the specified bus interrupt > level, I got a scrolling display of error messages on my debug monitor > indicating that a wrong VMEbus interrupt :0 was recieved ????????? That implies the interrupt vector number being returned by the hardware was read as a 0. > 2. Assuming that during the IACK ( interrupt acknowledge) cycle, the > interrupting board would send 0x60 as the Interrupt Number/Interrupt > Vector to the the SBC over the VME bus my call to intConnect should be > > intConnect (INUM_TO_IVEC (0x60), myVMEinterruptHandler, 0); or > intConnect (0x60, myVMEinterruptHandler, 0); The first one, INUM_TO_IVEC(0x60) > 3. I was under the impression that the intArchLib ( which is the > architecture-dependent interrupt library ) will provide the definition > of INUM_TO_IVEC. But from the code snippet above it looks like I have > to define it myself. So the question is who provides the definition of > INUM_TO_IVEC ? If I have to define it how do I do it ? Ignore the code snippet (which is for some unknown CPU), it's defined by your architecture, you just need to #include <iv.h> to get it (this is stated on the Reference Manual page for intArchLib). > I am NOT using sysBusIntGen() to simulate the generation of > interrupts, rather I am using our custom H/W boards to actually > generate interrupts across the VMEbus. We have verified that these > interrupts are actually getting generated and being transferred across > the VMEbus using probes, but are not able to connect an ISR which will > handle this interrupt on the SBC. Check the cycle timing on the VME interface of the slave boards - even if they are known to work with a 680x0-based CPU board they still might not work with the Tundra, which meets the VMEbus spec but doesn't produce the same typical timings as earlier interface chips used to. In particular check for address rot, as the Tundra can remove the Address Strobe earlier than the 68K designs used to, but there can be other similar kinds of timing issues leading to the wrong data being seen by the Tundra. - Andrew -- There are 10 types of people in the world: Those who understand binary, and those who don't.
相关文章推荐
- Q\A about VME bus for Vxworks
- about build portlets for Domino
- Link - iOS Layout about "edgesForExtendedLayout" and "automaticallyAdjustsScrollViewInsets"
- Some Posts about Tree for MVC
- CO-doc. number assignment not possible for bus.trans. COIN in CO area 1800 Message no. KC101
- Question about applying for colleges?
- about to fork child process, waiting until server is ready for connections. forked process: 2676 ERROR: child process failed, exited with error number 100
- Microsoft uaa bus driver for high definition audio
- VxWorks for PowerPC的内存分配
- About 2014 Air Jordan 12 Gamma Blue for govsneakernew
- Dos Batch execute about For
- nagios配置pnp4nagios报错“Please check the documentation for information about the following error”
- VxWorks for PowerPC的内存分配
- About Code Review Tools for Trac
- Collection View Programming Guide for iOS---(一)----About iOS Collection Views
- Wind River Opens IoT Marketplace for VxWorks OS
- About the Player cache for framework----[the client frameWork can be used by all player plug in]
- Table View Programming Guide for iOS---(一)---About Table Views in iOS Apps
- Event Handling Guide for iOS--(一)--About Events in iOS(翻译)
- [Windows Azure] About Affinity Groups for Virtual Network