How to pick the best VME interrupt Level & vector
Mike Anderson
> Submitted-by: gr...@eng.nmr.varian.com (Greg Brissey x6951)
>
> VxPerts,
>
> Maybe someone can help me out here. I have 3 - 4 VME boards I am
> controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is
> how to best pick the VME interrupt level and vectors for my boards.
> A different level for each board or a single level for all and let
> the order within the cardcage determine the relative priorities.
> Which level(s) do I pick? What vectors are safe to use. I
> obviously don't what to pick ones that VxWorks already uses.
> Or am I confused and are VME vectors different from the on board vectors.
>
> There must be some method to this madness.....
>
Well, it all depends on how you're trying to use the system and how
many other boards will be there. From your description, you could
do either approach and end up with a working system. However, a few
rules of thumb/explainations are perhaps in order.
I'm not that familiar with the 162LX per se, but in general (at least
for the 68K family, things are different for architectures such as
SPARC and i960) there are 256 interrupt vectors -- the first 100 (0x64)
are usually reserved. An interrupt vector is essentially nothing more
than a pointer to an interrupt handler (ISR). The hardware will
typically support both on-board hardware such as SCSI, Ethernet,
RS-232, etc. and off-board (i.e., VMEbus) hardware interrupts. The
hardware interrupt is then connected to a software vector either by
filling in the vector table directly (the vector table occupies the
first 0x400 bytes in a 68K address space by default) or via a mechanism
such as intConnect. The on-board interrupt sources do not generally
interfere with (i.e., occupy) any of the interrupt *levels* from the
VMEbus. You'll have to check your board (using Jeff Hill's fabulous
"veclist.c" code from the User's Group archives) to see with interrupt
vectors are attached in your system.
An interrupt *level* is a hardware signal from the VMEbus. You have
interrupt level *generators* and interrupt level *responders*. As
you've alluded to in your message, you know about the ability to have
multiple interrupt generators at the same level and just use the vector
to sort out *which* generator raised the interrupt level. During the
interrupt cycle on the bus, the generator (G) raises the level, the
responder (R) (you can only have one R per *level*) will assert the
interrupt acknowledge (IACK* -- remember the IACK pins on the bus that
have to be jumpered if you have an empty slot?) signal and the *first*
G on the daisy chain that's expecting an IACK* will intercept it. Then
the G arbitrates the bus and places the interrupt *vector* number on
the data lines. The R then responds with DTACK* (data transfer
acknowledge) and the interrupt *bus* cycle is complete. This is where
your ISR starts running (based on the interrupt vector number) and you
may do additional transfers on the bus to service the hardware.
What happens if the interrupt Gs are all at the same interrupt level is
that we get an inherent priority of the devices based on their physical
location in the bus (first card in the daisy chain is highest because
it has first "dibs" on the IACK* signal as it comes down the wire and
so on). In a system with lots of interrupt activity at the same level,
you get the same exponential decay of interrupt service that we see
in bus arbitration of requests at the same level. That is, the last
card in the rack gets the poorest service -- occasionally to the point
of the interrupt cycle failing entirely.
The VMEbus interrupt levels have a hard-wired priority where level 7
is highest and level 1 is lowest. I don't recommend using level 7
(there's been lots of discussion on this forum recently about the
reasons why so I won't belabor the discussion) so you boil down to
either using the hardwired priorities of the VMEbus levels, or the
de-facto priorities of the location of the card on the daisy chain.
Either way you have a priority-oriented scheme, but with different
levels, you have a more well-known (and hopefully better understood)
mechanism that allows you better control of the absolute priorities
of interrupts in your system. If you've got the levels to burn, I'd
use them. I'd only use the same level approach if I had lots of
boards in the system (especially if I've got say 6+ of one kind) and
couldn't give each board its own level. I'm not sure how the 162's
IP modules impact this discussion, but I believe that they will use
"on-board" interrupts and hence not interfere with the off-board
VMEbus levels.
Hope this helps,
===============================================================================
__ Real-Time System Development, Integration, Training and Services
//\\
// \\ Mike Anderson
// /\ \\ Director, Real-Time Systems
// / \ \\ SPARTA, Inc. Voice : (703) 448-0210 ext. 235
// \ \\ 7926 Jones Branch Drive FAX : (703) 734-3323
\\ \ // Suite 900 EMAIL : m...@mclean.sparta.com
\\ \ / // McLean, VA 22102
\\ \/ // "Software development is like making
\\ // a baby... You can't make a baby in one
\\// month by impregnating nine women.
-- "Pride in Performance" Some things just take time."
===============================================================================
Greg Brissey x6951
Maybe someone can help me out here. I have 3 - 4 VME boards I am
controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is
how to best pick the VME interrupt level and vectors for my boards.
A different level for each board or a single level for all and let
the order within the cardcage determine the relative priorities.
Which level(s) do I pick? What vectors are safe to use. I
obviously don't what to pick ones that VxWorks already uses.
Or am I confused and are VME vectors different from the on board vectors.
There must be some method to this madness.....
Thanks in advance,
Greg Brissey
greg.b...@nmr.varian.com
(415) 424-6951
George Eger (303) 971-6974
|> In article <941025232...@eng.nmr.varian.com>, gr...@eng.nmr.varian.com (Greg Brissey x6951) writes:
|> |> VxPerts,
|> |>
|> |> Maybe someone can help me out here. I have 3 - 4 VME boards I am
|> |> controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is
|> |> how to best pick the VME interrupt level and vectors for my boards.
|> |> A different level for each board or a single level for all and let
|> |> the order within the cardcage determine the relative priorities.
|> |> Which level(s) do I pick? What vectors are safe to use. I
|> |> obviously don't what to pick ones that VxWorks already uses.
|> |> Or am I confused and are VME vectors different from the on board vectors.
|> |>
|>
|> can find the interrupt vector table (frequently at the start of your on-board
|> RAM), you can determine which vectors are unused, since all unused vectors point
|> to the same entry point (excIntStub). If you disassemble the routine pointed to
|> by a used interrupt vector, you'll see something like:
|>
|> 403b1ea0 4eb9 4004 4faa JSR _intEnt
|> 403b1ea6 48e7 e0c0 MOVEM .L D0-D2/A0-A1,-(A7)
|> 403b1eaa 2f3c 0000 0001 MOVE .L #00001,-(A7)
|> 403b1eb0 4eb9 4000 276c JSR _tyCoIntWr
|> 403b1eb6 588f ADDQ .L #0x4,A7
|> 403b1eb8 4cdf 0307 MOVEM .L (A7)+,D0-D2/A0-A1
|> 403b1ebc 4ef9 4004 4fbc JMP _intExit
|> 403b1ec2 ffaf DC.W 0xffaf
|> 403b1ec4 403b DC.W 0x403b
|> 403b1ec6 1e98 MOVE .B (A0)+,(A7)
|>
|> Interrupt vectors 64-255 (offset 0x100-0x3fc) are available for use by interrupts
|> generated by your boards, assuming your MVME162LX isn't using them for on-board
|> devices. (You can look at your board support package to determine which on-board
|> devices use which interrupt vectors).
|>
|>
|> --
|> Joe VanAndel Internet: vana...@ncar.ucar.edu
|> National Center for Web http://www.atd.ucar.edu/jva/home.html
|> Atmospheric Research
I saw this and the original posting and had already created a utility,
map68KIVT, to do just that. I've mailed it to th...@ncar.ucar.edu, so it
should be in the vxWorks archives by now. It looks at the 256 interrupt
pointers and uses symFindByValueAndType() to try to lookup the name of the
ISR's. If anybody wants the source, and it's not in the archives, mail me
and I'll send you a copy.
GWE
||==========================================================================
||George Eger / ge...@den.mmc.com || Voice - (303) - 971 - 6974 ||
||Integ. Fault Tolerant Avionics || Fax - (303) - 977 - 1145 ||
||Space Launch Systems || MS T320 ||
||Martin Marietta Astronautics || P.O. Box 179, Denver CO 80201 ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans. ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own. ||
||==========================================================================
Joe Van Andel
|>
|> Maybe someone can help me out here. I have 3 - 4 VME boards I am
|> controlling with a MVME162LX running VxWorks 5.1.1. My dilemma is
|> how to best pick the VME interrupt level and vectors for my boards.
|> A different level for each board or a single level for all and let
|> the order within the cardcage determine the relative priorities.
|> Which level(s) do I pick? What vectors are safe to use. I
|> obviously don't what to pick ones that VxWorks already uses.
|> Or am I confused and are VME vectors different from the on board vectors.
|>
Wind River has a tech. note on how to determine which vectors are used. If you
can find the interrupt vector table (frequently at the start of your on-board
RAM), you can determine which vectors are unused, since all unused vectors point
to the same entry point (excIntStub). If you disassemble the routine pointed to
by a used interrupt vector, you'll see something like:
403b1ea0 4eb9 4004 4faa JSR _intEnt
403b1ea6 48e7 e0c0 MOVEM .L D0-D2/A0-A1,-(A7)
403b1eaa 2f3c 0000 0001 MOVE .L #00001,-(A7)
403b1eb0 4eb9 4000 276c JSR _tyCoIntWr
403b1eb6 588f ADDQ .L #0x4,A7
403b1eb8 4cdf 0307 MOVEM .L (A7)+,D0-D2/A0-A1
403b1ebc 4ef9 4004 4fbc JMP _intExit
403b1ec2 ffaf DC.W 0xffaf
403b1ec4 403b DC.W 0x403b
403b1ec6 1e98 MOVE .B (A0)+,(A7)
Interrupt vectors 64-255 (offset 0x100-0x3fc) are available for use by interrupts
generated by your boards, assuming your MVME162LX isn't using them for on-board
devices. (You can look at your board support package to determine which on-board
devices use which interrupt vectors).
Regarding choosing interrupts levels, first of all, don't use level 7 interrupts,
since no operating system (including VxWorks) can mask them out during critical
sections. It is generally better to use different interrupt levels, rather than
relying on the order within the cardcage, simply because it makes your system
easier to re-configure. If you decide to change the priority of different cards,
wouldn't you rather re-compile, rather than swap boards?
In general, you need to determine which of your boards has the highest priority
based on your application, and the characteristics of your boards. If a board
needs to be serviced within a given period of time to avoid losing data, then you
need to give it a higher interrupt priority level. For example, some serial I/O
cards have very little buffering for incoming characters, so if you are servicing
higher priority interrupts continuously, you could miss characters.