Reply by David ●December 13, 20022002-12-13
There is also one further feature of the 56300 family
to help in debugging in real-time: The ATE bit in the OMR
turns on the Address Trace.

Internal P memory accesses are reflected on the Port A
address lines, so you can follow the DSP through the
execution path with a logic analyzer. For the
details, see the chapter on debugging in the family
manual. I don't have the exact reference handy, but if
you can't find it, please let me know.

-david --- In , "John Wygonski" <jwygonski@h...>
wrote:
> > > 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?
>
> In addition to all the fine advice you received previously, you
should be
> aware of the context save/restore that is required for an ISR. Your ISR
> needs to save the state of all registers that it modifies, perform the
> required processing, and then restore these registers before
returning to
> the process that was interrupted. If you write an ISR in assembly, the
> burden is yours to do this correctly. If you write the ISR in C, the
> compiler takes care of it for you, which is nice. However, if you
make a
> function call in your ISR, and if the function is in another file, the
> compiler is forced to save nearly ALL regs, which adds considerable
> overhead.
>
> That said, I do all my coding in C (except, of course, for signal
filters
> and the like), including ISRs, and then see whether the program meets
> real-time constraints. If so, I'm done. If not, I recode in
assembly only
> those parts that require it for real-time. I started programming the
> DSP56xx family many years ago using the GNU C compiler, then
switched to the
> Tasking compiler about 6 years ago. I find that I need to work hard to
> improve the efficiency of the compiler, and I make as much use as
possible
> of the compiler's CPU specific features as I can, such as the _circ
extended
> data type, which implements circular buffers using the dedicated
hardware
> regs that the DSP has for this purpose.
>
> Regarding debugging ISRs, I also use the technique of toggling I/O
bits in
> my code and using a logic analyzer to monitor them along with other DSP
> signals such as timer output pins and frame syncs. It's the best
way to get
> good insight into any real-time software.
>
> Regards,
> John Wygonski
> House Ear Institute




Reply by John Wygonski ●December 13, 20022002-12-13
> > 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?

In addition to all the fine advice you received previously, you should be
aware of the context save/restore that is required for an ISR. Your ISR
needs to save the state of all registers that it modifies, perform the
required processing, and then restore these registers before returning to
the process that was interrupted. If you write an ISR in assembly, the
burden is yours to do this correctly. If you write the ISR in C, the
compiler takes care of it for you, which is nice. However, if you make a
function call in your ISR, and if the function is in another file, the
compiler is forced to save nearly ALL regs, which adds considerable
overhead.

That said, I do all my coding in C (except, of course, for signal filters
and the like), including ISRs, and then see whether the program meets
real-time constraints. If so, I'm done. If not, I recode in assembly only
those parts that require it for real-time. I started programming the
DSP56xx family many years ago using the GNU C compiler, then switched to the
Tasking compiler about 6 years ago. I find that I need to work hard to
improve the efficiency of the compiler, and I make as much use as possible
of the compiler's CPU specific features as I can, such as the _circ extended
data type, which implements circular buffers using the dedicated hardware
regs that the DSP has for this purpose.

Regarding debugging ISRs, I also use the technique of toggling I/O bits in
my code and using a logic analyzer to monitor them along with other DSP
signals such as timer output pins and frame syncs. It's the best way to get
good insight into any real-time software.

Regards,
John Wygonski
House Ear Institute