Help - Making Sense Of C30 Compiler Documentation On Interrupts

[DaveP]

From page 102 of the MPLAB C30 compiler documentation:

"The last nine interrupt vectors in each table (IVT) do not have
predefined hardware functions.
The vectors for these interrupts may be filled by using the names
indicated in the
preceding table, or, names more appropriate to the application may be
used, while still
filling the appropriate vector entry by using the irq or altirq
parameter of the
interrupt attribute. For example, to specify that a function should
use primary interrupt
vector fifty-two, use the following:
void __attribute__((__interrupt__(__irq__(52)))) MyIRQ(void);"

Does anyone know how one of these interrupts are triggered or why one
would want to fill the table entries? Neither the device data sheet
nor the FRM seems to shed any light on the above text.

[Bob]

Just a guess -- perhaps that is a catchall mechanism in the compiler
in the case that a new family member comes out that has a hardware
interrupt in one of those slots, but the compiler release is behind
and does not support a fixed name for that slot -- so you could use
this mechanism to fill in that ISR until the compiler release caught
up to that family member.

I know of nothing in the actual PIC24 architecture that would let you
trigger an unused interrupt vector, as you have pointed out.

[DaveP]

Bob,

Maybe. The compiler is very specific about only allowing IRQ#s
45-53. Based on the tables, these are listed as 'reserved' for the
dsPIC30F, but not the case for some of the others.

I was trying to emulate something done in a piece of code that I got
for the PIC32. I don't fully understand it, but it looks like the
programmer is, perhaps only for illustration purposes, triggering an
IRQ from software. I thought that maybe this was a way to do this
with the PIC24H.

Thanks for your reply.

[Dave]

DaveP,

I think you probably can emulate software interrupts using those
locations. You can’t call a normal ISR on a PIC24 but I think you
could populate one of those vector addresses to point to a regular
function. Then you can create a macro, sw_ISR, to load a pointer to a
function from the vector and call it. The "service routine" will
execute a normal return back to your “foreground” code.

[Bryan A. Jones]

I agree -- an assembly macro could also mimic interrupt operation by pushing the same info to the stack than an interrupt does, setting the IPL bits to a higher number, etc. so that a retfie returns to the place where the interrupt was called from. Thought I don't see a lot of use for this. Reminds me of good ol' DOS days -- int 21, anyone? and calls to BIOS?

Bryan

--

You received this message because you are subscribed to the Google Groups "PIC24 Assembly-to-C Book" group.
To post to this group, send email to pic24-assemb...@googlegroups.com.
To unsubscribe from this group, send email to pic24-assembly-to-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pic24-assembly-to-c-book?hl=en.

--
Bryan A. Jones, Ph.D.
Assistant Professor
Department of Electrical and Computer Engineering
231 Simrall / PO Box 9571
Mississippi State University
Mississippi state, MS 39762
http://www.ece.msstate.edu/~bjones
bjones AT ece DOT msstate DOT edu
voice 662-325-3149
fax 662-325-9438

Our Master, Jesus Christ, is on his way. He'll show up right on
time, his arrival guaranteed by the Blessed and Undisputed Ruler,
High King, High God.
- 1 Tim. 6:14b-15 (The Message)

[DaveP]

Slow down! I'm still learning this stuff. Other than to get this
PIC32 code to work on a PIC24, I too am not sure how useful this is.
That said, I still would like to understand this and see where it
might lead.

Before receiving these replies, what I did instead was to use the INT0
IRQ. I did this because I could create a simple C macro to trigger
the ISR by setting the _INT0IF. This illustrates my confusion. I
know how to get the INT0 ISR to trigger because there is a bit within
one of the ISFx registers that controls this. I'm not sure how you do
this with IRQ#s 45-53. Maybe this is what you just explained to me
but I'm not seeing it yet.

Thanks for the help.

On Dec 22, 2:19 pm, "Bryan A. Jones" <bjo...@ece.msstate.edu> wrote:
> I agree -- an assembly macro could also mimic interrupt operation by pushing
> the same info to the stack than an interrupt does, setting the IPL bits to a
> higher number, etc. so that a retfie returns to the place where the
> interrupt was called from. Thought I don't see a lot of use for this.
> Reminds me of good ol' DOS days -- int 21, anyone? and calls to BIOS?
>
> Bryan
>
>
>
>
>
> On Tue, Dec 22, 2009 at 3:05 PM, Dave <weaver...@gmail.com> wrote:
>
> > DaveP,
>
> > I think you probably can emulate software interrupts using those
> > locations. You can’t call a normal ISR on a PIC24 but I think you
> > could populate one of those vector addresses to point to a regular
> > function. Then you can create a macro, sw_ISR, to load a pointer to a
> > function from the vector and call it. The "service routine" will
> > execute a normal return back to your “foreground” code.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "PIC24 Assembly-to-C Book" group.
> > To post to this group, send email to
> > pic24-assemb...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > pic24-assembly-to-...@googlegroups.com<pic24-assembly-to-c-b­ook%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at
> >http://groups.google.com/group/pic24-assembly-to-c-book?hl=en.
>
> --
> Bryan A. Jones, Ph.D.
> Assistant Professor
> Department of Electrical and Computer Engineering
> 231 Simrall / PO Box 9571
> Mississippi State University

> Mississippi state, MS 39762http://www.ece.msstate.edu/~bjones

> bjones AT ece DOT msstate DOT edu
> voice 662-325-3149
> fax 662-325-9438
>
> Our Master, Jesus Christ, is on his way. He'll show up right on
> time, his arrival guaranteed by the Blessed and Undisputed Ruler,
> High King, High God.

> - 1 Tim. 6:14b-15 (The Message)- Hide quoted text -
>
> - Show quoted text -

[Dave]

Yes and the thrill of searching for undocumented instructions (I
wonder if the PIC24 has any?) and routines …

Merry Christmas!

[DaveP]

From my snowy Colorado home, Merry Christmas to you too.

[Dave]

DaveP,

What Dr. Jones said – and I agree – is that these approaches aren’t
likely to be generally useful. Now his approach has the advantage of a
more accurate emulation of an interrupt. Mine, perhaps, is simpler.

The first question you may want to investigate is why a SW interrupt
would be useful instead of a simple function call? The answer on
machines where a SW IRQ is provided generally lies in the realm of
protecting OS code from an application and/or one program space from
another. Also, it may require fewer bits/instructions, i.e. less
memory per call and faster.

So what I suggested is:
1. Write a port of the ISR as a regular function – no special ISR bit
manipulations or declarations. You can mask interrupts or set
processing level in this function as you desire.
2. You can just call the above ISR port and that should adequately
emulate your SW interrupt.
3. If you have a reason, you can additionally load one of the IRQ
vectors to point to the pseudo ISR declared above. Then you can use it
as a pointer or to load a pointer to the ISR function. These are
slightly challenging declarations. Then you can call the function via
the pointer. This jump table approach MAY have use in the large
memory model or to allow changing the processing routine under some
circumstance. See the C30 programming manual.

I am in Florida for the winter because I would rather dream of a white
Christmas then experience one.

Dave