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...>
> > > 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
> 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
> 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
> 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
> That said, I do all my coding in C (except, of course, for signal
> 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
> 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
> of the compiler's CPU specific features as I can, such as the _circ
> data type, which implements circular buffers using the dedicated
> regs that the DSP has for this purpose.
> Regarding debugging ISRs, I also use the technique of toggling I/O
> 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.
> John Wygonski
> House Ear Institute