> > 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 |
|
RE: Interrupts on the 56303
Started by ●December 13, 2002
Reply by ●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 |