|
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 |
|
|
Re: Interrupts on the 56303
Started by ●December 10, 2002
Reply by ●December 11, 20022002-12-11
|
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 |
Reply by ●December 12, 20022002-12-12
|
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 |
Reply by ●December 12, 20022002-12-12
|
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 |
