Hi all,
       When an interrupt is generated using an INTR instruction or TRAP
instruction, that interrupt is non-maskable and  the only difference between
these two instructions seems to be that TRAP instruction don't disable all
interrupts.

       Now why do you think these instructions have been made non-maskable?
I can understand a TRAP instruction being non-maskable. But shouldn't the
INTR instruction been left maskable?

       My problem is that, I would like to use a software interrupt to
trigger my task scheduler, so that I can have task pre-emption and task
scheduling without any delay (I don't want to use a timer). Basically the
tasks would be scheduled depending on external events which are received
through external interrupts and hence the decision to schedule the tasks
would be taken in interrupt service routines. It would have been good for me
if INTR instruction would raise a interrupt and as soon as I finish the ISR
(non-nested), the software interrupt would be triggered which would execute
the task scheduler. But now, the software interrupt would be executed on top
of the ISR if I use INTR or TRAP.

       Any ideas, thoughts on this?
Cheers,
Ajith.

Ajith-
>        When an interrupt is generated using an INTR instruction or TRAP
> instruction, that interrupt is non-maskable and  the only difference between these
> two instructions seems to be that TRAP instruction don't disable all interrupts.
>
>        Now why do you think these instructions have been made non-maskable? I can
> understand a TRAP instruction being non-maskable. But shouldn't the INTR
> instruction been left maskable?
>
>        My problem is that, I would like to use a software interrupt to trigger my
> task scheduler, so that I can have task pre-emption and task scheduling without any
> delay (I don't want to use a timer). Basically the tasks would be scheduled
> depending on external events which are received through external interrupts and
> hence the decision to schedule the tasks would be taken in interrupt service
> routines. It would have been good for me if INTR instruction would raise a
> interrupt and as soon as I finish the ISR (non-nested), the software interrupt
> would be triggered which would execute the task scheduler. But now, the software
> interrupt would be executed on top of the ISR if I use INTR or TRAP.

INTR software interrupts are affected by INTM like hardware interrupts.  If INTM is
set (which it should be inside ISR unless you manually cleared it), and you execute
INTR, then the software interrupt should wait until your ISR completes.  Is that what
you want?

A general question:  are you implementing task and other event-driven OS functions
instead of using DSP/BIOS?  If so I'm curious as to why?

-Jeff

Ajith-

Strike the first part of my previous reply.  I see in the instruction reference guide
doc where it says "[the INTR] instruction is executed regardless of the value of INTM
bit".  I was looking for "not maskable" so I missed that.

Well, if you really wanted a non-nested interrupt sequence, then possibly you could
connect a GPIO line to an external interrupt and set the GPIO bit in your ISR, using
the new external interrupt as a dedicated "task scheduler" ISR.  That's a bit
kludgy,
but it might work.

-Jeff

-------- Original Message --------
Subject: Re: [c55x] your say on INTR & TRAP
Date: Tue, 19 Dec 2006 11:43:42 -0600
From: Jeff Brower <j...@signalogic.com>
Organization: Signalogic, Inc
To: Ajith Kutty <a...@gmail.com>
CC: c...@yahoogroups.com

Ajith-
>        When an interrupt is generated using an INTR instruction or TRAP
> instruction, that interrupt is non-maskable and  the only difference between these
> two instructions seems to be that TRAP instruction don't disable all interrupts.
>
>        Now why do you think these instructions have been made non-maskable? I can
> understand a TRAP instruction being non-maskable. But shouldn't the INTR
> instruction been left maskable?
>
>        My problem is that, I would like to use a software interrupt to trigger my
> task scheduler, so that I can have task pre-emption and task scheduling without any
> delay (I don't want to use a timer). Basically the tasks would be scheduled
> depending on external events which are received through external interrupts and
> hence the decision to schedule the tasks would be taken in interrupt service
> routines. It would have been good for me if INTR instruction would raise a
> interrupt and as soon as I finish the ISR (non-nested), the software interrupt
> would be triggered which would execute the task scheduler. But now, the software
> interrupt would be executed on top of the ISR if I use INTR or TRAP.

INTR software interrupts are affected by INTM like hardware interrupts.  If INTM is
set (which it should be inside ISR unless you manually cleared it), and you execute
INTR, then the software interrupt should wait until your ISR completes.  Is that what
you want?

A general question:  are you implementing task and other event-driven OS functions
instead of using DSP/BIOS?  If so I'm curious as to why?

-Jeff

Hi Jeff,
         Can you think of any reason why INTR instruction should be like
that? I mean there should be a design philosophy behind it, considering
there is a TRAP instruction also exists.

         On the general question: Yes we have our own custom task scheduler
to do event driven tasks. I did tried DSP/BIOS, but it only looks great in
the documentation. Its consuming way too much MIPS and memory. If I want to
schedule a task from an interrupt service routine (or do most of the OS
functions from an ISR), i have to add a header and footer to the ISR
routine. I had a look at this header in mixed mode view and then I had to
say no to DSP/BIOS :-) ...

         The whole ISR takes 2uS to execute, with the header it takes 4uS (I
couldn't measure the footer as it is not in my control). But looking at the
mixed mode, I would assume the ISR would take 6uS if I use DSP/BIOS, whereas
it would take only 2uS otherwise. It could be due to bad architecture of our
system, or I have not done something proper. Please advice if you think so.
(We use C54x compatibility mode for some of the old libraries in the system,
so there is C54x stack mode).
Cheers,
Ajith.

On 12/19/06, Jeff Brower <j...@signalogic.com> wrote:
>
> Ajith-
>
> Strike the first part of my previous reply.  I see in the instruction
> reference guide
> doc where it says "[the INTR] instruction is executed regardless of the
> value of INTM
> bit".  I was looking for "not maskable" so I missed that.
>
> Well, if you really wanted a non-nested interrupt sequence, then possibly
> you could
> connect a GPIO line to an external interrupt and set the GPIO bit in your
> ISR, using
> the new external interrupt as a dedicated "task scheduler" ISR.  That's a
> bit kludgy,
> but it might work.
>
> -Jeff
>
> -------- Original Message --------
> Subject: Re: [c55x] your say on INTR & TRAP
> Date: Tue, 19 Dec 2006 11:43:42 -0600
> From: Jeff Brower <j...@signalogic.com>
> Organization: Signalogic, Inc
> To: Ajith Kutty <a...@gmail.com>
> CC: c...@yahoogroups.com
>
> Ajith-
> >        When an interrupt is generated using an INTR instruction or TRAP
> > instruction, that interrupt is non-maskable and  the only difference
> between these
> > two instructions seems to be that TRAP instruction don't disable all
> interrupts.
> >
> >        Now why do you think these instructions have been made
> non-maskable? I can
> > understand a TRAP instruction being non-maskable. But shouldn't the INTR
> > instruction been left maskable?
> >
> >        My problem is that, I would like to use a software interrupt to
> trigger my
> > task scheduler, so that I can have task pre-emption and task scheduling
> without any
> > delay (I don't want to use a timer). Basically the tasks would be
> scheduled
> > depending on external events which are received through external
> interrupts and
> > hence the decision to schedule the tasks would be taken in interrupt
> service
> > routines. It would have been good for me if INTR instruction would raise
> a
> > interrupt and as soon as I finish the ISR (non-nested), the software
> interrupt
> > would be triggered which would execute the task scheduler. But now, the
> software
> > interrupt would be executed on top of the ISR if I use INTR or TRAP.
>
> INTR software interrupts are affected by INTM like hardware
> interrupts.  If INTM is
> set (which it should be inside ISR unless you manually cleared it), and
> you execute
> INTR, then the software interrupt should wait until your ISR
> completes.  Is that what
> you want?
>
> A general question:  are you implementing task and other event-driven OS
> functions
> instead of using DSP/BIOS?  If so I'm curious as to why?
>
> -Jeff
>

Ajith-
>          Can you think of any reason why INTR instruction should be like that? I
> mean there should be a design philosophy behind it, considering there is a TRAP
> instruction also exists.

All I can think of is that since 54xx devices worked the same way, maybe TI treated
this situation as "legacy" due to DSP/BIOS operation, or some other software
support,
when they designed the 55xx series.
>          On the general question: Yes we have our own custom task scheduler to do
> event driven tasks. I did tried DSP/BIOS, but it only looks great in the
> documentation. Its consuming way too much MIPS and memory. If I want to schedule a
> task from an interrupt service routine (or do most of the OS functions from an
> ISR), i have to add a header and footer to the ISR routine. I had a look at this
> header in mixed mode view and then I had to say no to DSP/BIOS :-) ...

Ok.  If you need to extract absolute maximum MIPS then DSP/BIOS does have an
impact...
>          The whole ISR takes 2uS to execute, with the header it takes 4uS (I
> couldn't measure the footer as it is not in my control). But looking at the mixed
> mode, I would assume the ISR would take 6uS if I use DSP/BIOS, whereas it would
> take only 2uS otherwise. It could be due to bad architecture of our system, or I
> have not done something proper. Please advice if you think so. (We use C54x
> compatibility mode for some of the old libraries in the system, so there is C54x
> stack mode).

4 usec is a lot of extra time.  If your 5502 clock is 300 MHz, that's around 12000
instructions, which sounds like way too many for DSP/BIOS ISR prologue and epilogue
code.  Is your code in external SRAM?  Maybe instruction cache is not handling enough
of this and forcing slow external mem accesses.

-Jeff
> On 12/19/06, Jeff Brower <j...@signalogic.com> wrote:
>
>       Ajith-
>
>      Strike the first part of my previous reply.  I see in the instruction
>      reference guide
>      doc where it says "[the INTR] instruction is executed regardless of the
>      value of INTM
>      bit".  I was looking for "not maskable" so I missed that.
>
>      Well, if you really wanted a non-nested interrupt sequence, then possibly
>      you could
>      connect a GPIO line to an external interrupt and set the GPIO bit in your
>      ISR, using
>      the new external interrupt as a dedicated "task scheduler" ISR.  That's a
>      bit kludgy,
>      but it might work.
>
>      -Jeff
>
>      -------- Original Message --------
>      Subject: Re: [c55x] your say on INTR & TRAP
>      Date: Tue, 19 Dec 2006 11:43:42 -0600
>      From: Jeff Brower < j...@signalogic.com>
>      Organization: Signalogic, Inc
>      To: Ajith Kutty <a...@gmail.com>
>      CC: c...@yahoogroups.com
>
>      Ajith-
>      >        When an interrupt is generated using an INTR instruction or TRAP
>
>      > instruction, that interrupt is non-maskable and  the only difference
>      between these
>      > two instructions seems to be that TRAP instruction don't disable all
>      interrupts.
>      >
>      >        Now why do you think these instructions have been made
>      non-maskable? I can
>      > understand a TRAP instruction being non-maskable. But shouldn't the
>      INTR
>      > instruction been left maskable?
>      >
>      >        My problem is that, I would like to use a software interrupt to
>      trigger my
>      > task scheduler, so that I can have task pre-emption and task scheduling
>      without any
>      > delay (I don't want to use a timer). Basically the tasks would be
>      scheduled
>      > depending on external events which are received through external
>      interrupts and
>      > hence the decision to schedule the tasks would be taken in interrupt
>      service
>      > routines. It would have been good for me if INTR instruction would
>      raise a
>      > interrupt and as soon as I finish the ISR (non-nested), the software
>      interrupt
>      > would be triggered which would execute the task scheduler. But now, the
>      software
>      > interrupt would be executed on top of the ISR if I use INTR or TRAP.
>
>      INTR software interrupts are affected by INTM like hardware interrupts.
>      If INTM is
>      set (which it should be inside ISR unless you manually cleared it), and
>      you execute
>      INTR, then the software interrupt should wait until your ISR completes.
>      Is that what
>      you want?
>
>      A general question:  are you implementing task and other event-driven OS
>      functions
>      instead of using DSP/BIOS?  If so I'm curious as to why?
>
>      -Jeff
>

Ajith-

> The C55x core is running on a 144MHz clock and all the code & data is in
> internal memory.

Ok... maybe you can use breakpoints to follow the DSP/BIOS ISR header code and verify
that it really eats 7000 instructions.  I know that's tedious, but there must be
something else going on, otherwise too much code for an ISR.

-Jeff

On 12/20/06, Jeff Brower < j...@signalogic.com> wrote:

       Ajith-

                  Can you think of any reason why INTR instruction should be like
that? I mean there should be a design philosophy behind it, considering there
         is a TRAP instruction also exists.

       All I can think of is that since 54xx devices worked the same way, maybe TI
treated this situation as "legacy" due to DSP/BIOS operation, or some other
       software support, when they designed the 55xx series.

                  On the general question: Yes we have our own custom task scheduler
to do event driven tasks. I did tried DSP/BIOS, but it only looks great in
         the documentation. Its consuming way too much MIPS and memory. If I want to
schedule a task from an interrupt service routine (or do most of the OS
          functions from an ISR), i have to add a header and footer to the ISR
routine. I had a look at this header in mixed mode view and then I had to say no
         to DSP/BIOS :-) ...
       Ok.  If you need to extract absolute maximum MIPS then DSP/BIOS does have an
impact...

                  The whole ISR takes 2uS to execute, with the header it takes 4uS (I
couldn't measure the footer as it is not in my control). But looking at
         the mixed mode, I would assume the ISR would take 6uS if I use DSP/BIOS,
whereas it would take only 2uS otherwise. It could be due to bad architecture
         of our system, or I have not done something proper. Please advice if you
think so. (We use C54x compatibility mode for some of the old libraries in
         the system, so there is C54x stack mode).
       4 usec is a lot of extra time.  If your 5502 clock is 300 MHz, that's around
12000 instructions, which sounds like way too many for DSP/BIOS ISR prologue
       and epilogue code.  Is your code in external SRAM?  Maybe instruction cache is
not handling enough of this and forcing slow external mem accesses. 

       -Jeff

Ajith--
Hope you have checked this documentation before going ahead on the
home-grown scheduler:

http://focus.ti.com/lit/an/spraa16d/spraa16d.pdf

--Bhooshan
On 12/20/06, Ajith Kutty <a...@gmail.com> wrote:
>
>   Hi Jeff,
>          Can you think of any reason why INTR instruction should be like
> that? I mean there should be a design philosophy behind it, considering
> there is a TRAP instruction also exists.
>
>          On the general question: Yes we have our own custom task
> scheduler to do event driven tasks. I did tried DSP/BIOS, but it only looks
> great in the documentation. Its consuming way too much MIPS and memory. If I
> want to schedule a task from an interrupt service routine (or do most of the
> OS functions from an ISR), i have to add a header and footer to the ISR
> routine. I had a look at this header in mixed mode view and then I had to
> say no to DSP/BIOS :-) ...
>
>          The whole ISR takes 2uS to execute, with the header it takes 4uS
> (I couldn't measure the footer as it is not in my control). But looking at
> the mixed mode, I would assume the ISR would take 6uS if I use DSP/BIOS,
> whereas it would take only 2uS otherwise. It could be due to bad
> architecture of our system, or I have not done something proper. Please
> advice if you think so. (We use C54x compatibility mode for some of the old
> libraries in the system, so there is C54x stack mode).
> Cheers,
> Ajith.
>
> On 12/19/06, Jeff Brower <j...@signalogic.com> wrote:
> >
> > Ajith-
> >
> > Strike the first part of my previous reply.  I see in the instruction
> > reference guide
> > doc where it says "[the INTR] instruction is executed regardless of the
> > value of INTM
> > bit".  I was looking for "not maskable" so I missed that.
> >
> > Well, if you really wanted a non-nested interrupt sequence, then
> > possibly you could
> > connect a GPIO line to an external interrupt and set the GPIO bit in
> > your ISR, using
> > the new external interrupt as a dedicated "task scheduler" ISR.  That's
> > a bit kludgy,
> > but it might work.
> >
> > -Jeff
> >
> > -------- Original Message --------
> > Subject: Re: [c55x] your say on INTR & TRAP
> > Date: Tue, 19 Dec 2006 11:43:42 -0600
> > From: Jeff Brower < j...@signalogic.com>
> > Organization: Signalogic, Inc
> > To: Ajith Kutty <a...@gmail.com>
> > CC: c...@yahoogroups.com
> >
> > Ajith-
> >
> >
> > >        When an interrupt is generated using an INTR instruction or
> > TRAP
> > > instruction, that interrupt is non-maskable and  the only difference
> > between these
> > > two instructions seems to be that TRAP instruction don't disable all
> > interrupts.
> > >
> > >        Now why do you think these instructions have been made
> > non-maskable? I can
> > > understand a TRAP instruction being non-maskable. But shouldn't the
> > INTR
> > > instruction been left maskable?
> > >
> > >        My problem is that, I would like to use a software interrupt to
> > trigger my
> > > task scheduler, so that I can have task pre-emption and task
> > scheduling without any
> > > delay (I don't want to use a timer). Basically the tasks would be
> > scheduled
> > > depending on external events which are received through external
> > interrupts and
> > > hence the decision to schedule the tasks would be taken in interrupt
> > service
> > > routines. It would have been good for me if INTR instruction would
> > raise a
> > > interrupt and as soon as I finish the ISR (non-nested), the software
> > interrupt
> > > would be triggered which would execute the task scheduler. But now,
> > the software
> > > interrupt would be executed on top of the ISR if I use INTR or TRAP.
> >
> > INTR software interrupts are affected by INTM like hardware
> > interrupts.  If INTM is
> > set (which it should be inside ISR unless you manually cleared it), and
> > you execute
> > INTR, then the software interrupt should wait until your ISR
> > completes.  Is that what
> > you want?
> >
> > A general question:  are you implementing task and other event-driven OS
> > functions
> > instead of using DSP/BIOS?  If so I'm curious as to why?
> >
> > -Jeff
> 
-- 
-------------------------------------------------------------------
"I've missed more than 9000 shots in my career.
I've lost almost 300 games. 26 times I've been trusted to take the game
winning shot and missed.
I've failed over and over again in my life.
And that is why I succeed."
        -- Michael Jordan
--------------------------------------------------------------------