Forums

Re: Interrupts on the 56303

Started by Graeme Fisher December 10, 2002
Hi all

Does anyone know how long in clock cycles it takes for an interrupt to
be serviced form the time that the interrupt occurs?

I have set up one of my host port pins as an output and am using the
timer1 compare interrupt to toggle that pin. If I set the reload value
to less than 80, then the frequency of oscillation of that pin starts to
decrease as if I am losing interrupts. All my interrupt routine does is
to toggle the host port pin. During the ISR i disable all interrupts and
re-enable them at the end. The best frequency that I can obtain on the
output pin is about 500kHz. If the time that it takes for the interrupt
to be serviced plus the time that it takes for my ISR to run is greater
that the time between timer interrupts, could this lead to missing
interrupts?

Also, is it a better idea to write ISR in assembler or C? Or does it
depend on the compiler? I am currently using the GNU C compiler.

What is the best way to debug programs that use interrupts?

Regards
Graeme



You should not need to disable and re-enable the interrupts in
your interrupt service routine. The interrupt priorities are
there for the prioritization of the interrupts so the most
important things can interrupt less important ones.

By disabling and re-enabling the interrupts, you incur the latency
for the disabling to take effect and again for the enabling to
take effect. You will lose any interrupts that occur during the
latent period where interrupts are not re-enabled.

You should be able to use a fast interrupt that toggles the
pin which should give you the maximum interrupt frequency.

--david --- In , "Graeme Fisher" <gf@n...> wrote:
> Hi all
>
> Does anyone know how long in clock cycles it takes for an interrupt
to
> be serviced form the time that the interrupt occurs?
>
> I have set up one of my host port pins as an output and am using the
> timer1 compare interrupt to toggle that pin. If I set the reload
value
> to less than 80, then the frequency of oscillation of that pin
starts to
> decrease as if I am losing interrupts. All my interrupt routine
does is
> to toggle the host port pin. During the ISR i disable all
interrupts and
> re-enable them at the end. The best frequency that I can obtain on
the
> output pin is about 500kHz. If the time that it takes for the
interrupt
> to be serviced plus the time that it takes for my ISR to run is
greater
> that the time between timer interrupts, could this lead to missing
> interrupts?
>
> Also, is it a better idea to write ISR in assembler or C? Or does it
> depend on the compiler? I am currently using the GNU C compiler.
>
> What is the best way to debug programs that use interrupts?
>
> Regards
> Graeme


Hi,
The Interrupt latency is dependant on a number of factors.

The smallest latency is determined by the time it takes the interrupt latch
to register the change on the interrupt input pin - usually so fast it
doesn't matter!

Next is the time taken to complete the currently executing instruction -
pretty quick for most instructions but the REP instruction cannot be
interrupted and so may take a (very) long time to complete if the loop
repeats many times.

Interrupt priority is important too - your high speed interrupt should be at
the highest priority level so that it can interrupt all lower level
interrupts (and will block any other interrupts at the same level). This
way you should not need to waste time and program code disabling other
interrupts inside your interrupt routine.

I do everything in assembler so can't really comment how good C is. It is
almost certainly slower unless it has a very good optimiser and you provide
all the appropriate hints (PRAGMA's) in the C code to help it do it's job
properly.
For instance, toggling a bit on a port when an interrupt occurs may only
require one or two assembler instructions, allowing the DSP Fast Interrupt
mode to be used. It will not require any messing with stacks and will not
cause any pipeline stalls or flushes. The only proviso is that the
instructions must not take up more than 2 words so choosing the most
efficient port addressing mode is very important.
On the other hand C is likely to jump out of the fast interrupt to a
separate subroutine regardless of its complexity, consuming some stack space
(maybe even causing a stack extension interrupt to consume more time!), and
adds a JMP and RETI instruction at the least to the code execution time.
For more complex interrupt handlers both assembler and C programs will have
this overhead.

Finally, the DSP always executes at least one lower level instruction
between interrupt calls, so you can't jam a interrupt line low and have it
execute the interrupt routine exclusively forever.

The best way I've found for debugging interrupts is to toggle spare DSP pins
to indicate various program states and look at these with a multi channel
storage CRO or logic analyser. Unfortunately there usually isn't any room
for extra toggle instructions within a Fast Interrupt so you may need to be
creative and monitor everything that happens around it.
Using debuggers through the OnCE port is a problem with real time programs
as it has to occasionally stop the DSP to interrogate it an will loose
hardware generated interrupts.

Hope this helps
Mark,
Bionic Ear Institute
University of Melbourne
Australia > -----Original Message-----
> From: Graeme Fisher [mailto:]
> Sent: Tuesday, December 10, 2002 7:17 PM
> To:
> Subject: [motoroladsp] Re: Interrupts on the 56303 > Hi all
>
> Does anyone know how long in clock cycles it takes for an interrupt to
> be serviced form the time that the interrupt occurs?
>
> I have set up one of my host port pins as an output and am using the
> timer1 compare interrupt to toggle that pin. If I set the reload value
> to less than 80, then the frequency of oscillation of that
> pin starts to
> decrease as if I am losing interrupts. All my interrupt
> routine does is
> to toggle the host port pin. During the ISR i disable all
> interrupts and
> re-enable them at the end. The best frequency that I can obtain on the
> output pin is about 500kHz. If the time that it takes for the
> interrupt
> to be serviced plus the time that it takes for my ISR to run
> is greater
> that the time between timer interrupts, could this lead to missing
> interrupts?
>
> Also, is it a better idea to write ISR in assembler or C? Or does it
> depend on the compiler? I am currently using the GNU C compiler.
>
> What is the best way to debug programs that use interrupts?
>
> Regards
> Graeme



Hi,
The Interrupt latency is dependant on a number of factors.

The smallest latency is determined by the time it takes the interrupt latch
to register the change on the interrupt input pin - usually so fast it
doesn't matter!

Next is the time taken to complete the currently executing instruction -
pretty quick for most instructions but the REP instruction cannot be
interrupted and so may take a (very) long time to complete if the loop
repeats many times.

Interrupt priority is important too - your high speed interrupt should be at
the highest priority level so that it can interrupt all lower level
interrupts (and will block any other interrupts at the same or lower level).
This
way you should not need to waste time and program code disabling other
interrupts inside your interrupt routine.

I do everything in assembler so can't really comment how good C is. It is
almost certainly slower unless it has a very good optimiser and you provide
all the appropriate hints (PRAGMA's) in the C code to help it do it's job
properly.
For instance, toggling a bit on a port when an interrupt occurs may only
require one or two assembler instructions, allowing the DSP Fast Interrupt
mode to be used. It will not require any messing with stacks and will not
cause any pipeline stalls or flushes. The only proviso is that the
instructions must not take up more than 2 words so choosing the most
efficient port addressing mode is very important.
On the other hand C is likely to jump out of the fast interrupt to a
separate subroutine regardless of its complexity, consuming some stack space
(maybe even causing a stack extension interrupt to consume more time!), and
adds a JMP and RETI instruction at the least to the code execution time.
For more complex interrupt handlers both assembler and C programs will have
this overhead.

Finally, the DSP always executes at least one lower level instruction
between interrupt calls, so you can't jam a interrupt line low and have it
execute the interrupt routine exclusively forever.

The best way I've found for debugging interrupts is to toggle spare DSP pins
to indicate various program states and look at these with a multi channel
storage CRO or logic analyser. Unfortunately there usually isn't any room
for extra toggle instructions within a Fast Interrupt so you may need to be
creative and monitor everything that happens around it.
Using debuggers through the OnCE port is a problem with real time programs
as it has to occasionally stop the DSP to interrogate it an will loose
hardware generated interrupts.

Hope this helps
Mark,
Bionic Ear Institute
University of Melbourne
Australia > -----Original Message-----
> From: Graeme Fisher [mailto:]
> Sent: Tuesday, December 10, 2002 7:17 PM
> To:
> Subject: [motoroladsp] Re: Interrupts on the 56303 > Hi all
>
> Does anyone know how long in clock cycles it takes for an interrupt to
> be serviced form the time that the interrupt occurs?
>
> I have set up one of my host port pins as an output and am using the
> timer1 compare interrupt to toggle that pin. If I set the reload value
> to less than 80, then the frequency of oscillation of that
> pin starts to
> decrease as if I am losing interrupts. All my interrupt
> routine does is
> to toggle the host port pin. During the ISR i disable all
> interrupts and
> re-enable them at the end. The best frequency that I can obtain on the
> output pin is about 500kHz. If the time that it takes for the
> interrupt
> to be serviced plus the time that it takes for my ISR to run
> is greater
> that the time between timer interrupts, could this lead to missing
> interrupts?
>
> Also, is it a better idea to write ISR in assembler or C? Or does it
> depend on the compiler? I am currently using the GNU C compiler.
>
> What is the best way to debug programs that use interrupts?
>
> Regards
> Graeme